六项贯穿每个项目的原则——不是墙上的口号，而是指导日常工程决策的承诺。
每个项目都从理解领域开始——物理约束、操作词汇、关键故障模式。对于 BESS 运营商而言，这意味着在写第一行查询之前，就要弄清楚 SOH 退化到底会损失多少调度收入。对于广播商而言，意味着理解为何单个帧在接收端丢失，就可能导致整个交付包不合规。
领域知识不是客户提供、我们照单全收的东西。我们主动投入：阅读标准文档、运行仿真、提出那些看似基础的问题——因为恰恰是这些问题，往往能避免项目后期代价高昂的返工。
因此，我们的估算立足于领域实际，而非对过往项目的乐观类比。当范围中存在不确定性时，我们明确指出，而不是悄悄将其吸收进交付缓冲区。
复杂系统不会自行简化——每个抽象层都需要刻意为之。我们将架构决策视为沟通产物：组件边界是关于哪些事物独立变化的声明；数据模型是关于系统需要了解什么的声明。
在实践中，这意味着我们抵制使用框架来解决尚不存在的问题。当确实需要引入依赖时，我们记录原因以及移除它的代价。目标是让后续工程师能从代码结构中读懂意图，而不仅仅依赖注释。
用户界面承担同等责任。需要专门培训才能读懂的仪表盘，在关键时刻必然遭到忽视。我们为凌晨两点盯着这些数据的运营人员设计，而不是为演示环境设计。
看不见进展会引发焦虑，焦虑催生仓促决策。我们分享进行中的工作——不是精心打磨的交付物，而是可运行的原型和粗稿，让客户在投入固化之前就能给出反馈。
当一项技术决策涉及重要权衡时，我们明确呈现权衡本身，而不是直接给出结论。当范围假设被证明有误时，我们立即告知，而不是悄悄调整交付时间表来掩盖偏差。
这同样适用于负面发现。如果我们提出的技术随着了解加深被证明并不合适，我们会直说。早期纠正的代价几乎总是低于晚期纠正。
代码质量是必要条件，但并不充分。一个测试良好却解决了错误问题、或晚了六周交付的模块，没有创造任何价值。我们将交付可靠性视为与测试覆盖率、性能基准并列的一级质量指标。
我们使用 CI/CD、类型系统和 linter，不是因为时髦，而是因为它们降低了下一次变更的成本。我们在维护成本最低、最可能捕捉真实回归的层级编写测试。分析性能瓶颈再优化，优化之后再考虑重写。
承诺交付日期时，我们同时承诺支撑这一日期的范围和假设。若假设发生变化，时间表重新开放——我们会立即告知。
打算替换的原型鲜少真正被替换。当我们构建要在生产环境中运行的东西，从第一个 commit 起就按生产标准对待：环境一致性、结构化日志、错误边界、部分故障下的优雅降级。
对于实时系统，这意味着在第一个 WebSocket 连接建立之前就考虑背压。对于大规模处理遥测数据的仪表盘，意味着在渲染第一张图表之前就考虑负载下的数据模型。对于流媒体管道，意味着用真实运营条件下的码率和延迟测试，而非演示条件。
我们不会在项目末尾请求清理冲刺。那个冲刺的代价始终高于整个过程中的持续关注，而且最终系统的整体性也更差。
完成的项目不是结果，而是里程碑。结果是一个随着需求演进、规模变化和领域本身转型而持续提供价值的系统。我们从一开始就为这一轨迹设计：扩展点、有文档记录的决策依据，以及让客户团队在没有我们的情况下真正能够继续的交接。
我们更愿意与把我们当作长期技术合作伙伴的客户合作，而非只把我们当作交付供应商。不是出于商业关系，而是因为当我们对业务背景理解足够深入、能够质疑那些十二个月后会出问题的规格时，工作才会更出色。
项目结束时，我们积累的知识属于客户，而非我们自己。文档、架构图和运行手册是每次交付的组成部分。