方法论 · SFDS
工程化 > 模型能力
模型会持续变强，这不是护城河。真正决定交付质量的，是工程化程度：需求是否被结构化、接口是否有契约、改动是否被测试锁定、发布是否有门禁。
问题
AI 编码时代，为什么还需要方法论
模型能写代码，但不能替你对交付负责。质量的下限由流程决定，不由模型决定。
机械门禁
接口契约、前后端路径、类型定义由脚本自动校验，不一致就直接失败。把「记得检查」变成「不通过就跑不起来」。
变更包治理
方法论本身的演进以「变更包」为单位发布，附适配说明与验收清单，跨项目统一、不各做各的。
声明式设计资产
设计产物以「数据 + 渲染器」分离形态沉淀，数据是唯一真相源，避免文档与实现各说各话。
流程
一个项目的五个阶段
每个阶段都有明确的输入、产物与出口门禁。出口不达标就不进入下一阶段。
01
标准先行
项目启动即确定开发标准与验收口径，避免中途扯皮。
02
结构化设计
业务流、数据模型、接口契约全部结构化沉淀，可追溯、可复查。
03
门禁校验
接口契约、前后端路径、类型定义由脚本机械对齐，不一致直接失败。
04
测试锁定
关键路径先写测试后写实现，回归可重跑、结果可举证。
05
分层发布
预发与正式分离，发布前后各有核对清单，出问题可回滚。
实证
这套标准不是 PPT
它已经在多个交付项目中实际运行，并用于统一跨项目的方法论版本。
可触发技能22+ 项
交付阶段5 段
工程化机制3 项
方法论起始2026-06
对客户意味着什么
- 过程可预期：阶段、产物、验收标准事先说清。
- 质量可举证：测试与校验结果可重跑，不靠口头承诺。
- 接手成本低：设计与实现有结构化的对应关系。
- 后续可维护：不依赖某个人「记得」系统是怎么运作的。
一句实话：这套标准会增加前期设计的时间投入。对于一次性、极小的需求，可能不划算——但我们更愿意做能长期维护的系统。