Approach / 01
先判断，
再建造。
好的系统不是把功能堆在一起，而是先想清楚：为谁解决什么问题、哪些流程必须可靠、哪些东西可以晚一点做。我们把这个判断过程写进交付里。
Principles / 02
三条不
妥协的原则。
它们决定了我们如何报价、如何拒绝、如何交付。也是我们和“便宜但失控”的项目之间的分界线。
范围先于价格
没有范围的价格没有意义。我们先确认交付物、排除项、依赖与验收标准，再给出固定报价。
系统先于页面
页面只是系统的表面。内容模型、权限、数据、支付与运维，决定这个网站能不能长期运转。
证据先于承诺
不承诺“保证转化”。我们承诺可控的交付：性能、可访问性、代码质量、文档与可验证的结果。
Process / 03
四个阶段，
一条交付链。
每个阶段都有明确产出和验收点。你不需要懂代码，但你会知道现在走到哪里、下一步是什么。
01 · Diagnostic
诊断
访谈、内容盘点、竞品与系统现状。输出目标、用户路径、范围建议、风险清单与预算区间。付费诊断可抵扣项目款。
02 · Design
设计
信息架构、视觉方向、关键页面、组件与动效规范。先做能验证方向的页面，再做完整系统，不在第一版堆满想法。
03 · Build
建造
前端、后端、内容模型、集成与性能。按里程碑交付，每个阶段可验收；范围变更进入变更单，不靠口头承诺。
04 · Care
交付与迭代
上线、监测、培训与文档。需要长期支持的项目进入 Care，持续做性能、安全、内容与功能迭代。
Boundaries / 04
我们会说
“不”。
拒绝不合适的需求，是对交付质量的一部分。下面这些情况，我们通常会建议换一种方式，或者不合作。
A
没有明确目标
“先做一个看看”通常意味着范围会无限扩张。我们建议先做付费诊断，把目标、用户和优先级写清楚。
B
只比价格
如果决策标准只有“谁更便宜”，我们通常不是最合适的选择。低价项目很难覆盖设计、性能和长期维护的成本。
C
需要保证结果
我们能对交付物、性能与技术质量负责，但不能在没有基线数据的情况下承诺转化率或收入。