和 AI 结对开发 2000+ 小时后，我总结出数字服务开发的新范式

过去几周，我和 AI 结对开发我的 AI 督导师产品。协作中踩了一串坑：一个"收件箱"功能因为需求描述散落在多处，返工了好几轮；一个功能只做了语法检查就往下走，直到后面才发现没在真实页面里跑通过；还有一次，工作区里堆着 89 处未提交的改动，每一次修改都像在猜谜。

复盘这些坑的时候，我发现它们指向同一套底层方法——一套在 AI 协同开发场景下，让数字化服务先站得住、再长起来的方法。这篇文章把这套方法完整写出来，给同样在AI协同做产品的你。

一句话结论

优秀的数字化服务 = 工程底座 × 五层产品勾勒 × 两种形态（晶体化 → 生命化）× 落地展开 × 验证分层 × 一线迭代回路。

前三件事解决「做对的事且不返工」，后三件事解决「做出一个能长起来的东西」。绝大多数项目卡住，不是技术不够，而是底座没打就往上砌界面，或者结构没定就急着上线迭代。

A. 工程底座：四条不产出功能、但决定成本的纪律

A1. 单一真相源。 设计稿是唯一需求源，CHANGELOG 是唯一任务真相源。每个决定都写进去，包括"决定不改什么"。判据很简单：同一个决定在三份文档里说法不同，等于它没有发生过。我的"收件箱"返工，根因就是多处描述并存——歧义不会自己消失，它只会变成返工。

A2. 版本管理。 一个功能 = 一次语义完整的提交。大改之前先把工作区理清——89 处未提交改动意味着，任何一次 debug 都是在猜。

A3. 任务管理。 任务粒度对齐到"一次可验证的改动"，而不是"一个模块"。完成标准必须是可验证的动作，不是"感觉差不多了"。

A4. 小步提交。 每次改动是一个可独立验证的最小单元。出问题时，嫌疑范围只有一个 diff。

外加一条输入纪律：参考图、截图、链接，必须带一句文字说明。这几轮协作里有两次图片没带说明，AI 只能多问一轮——缺说明的输入就是一次空转。

B. 需求五层勾勒：从抽象到具体

想清楚再动手。五层的顺序是硬约束：上一层没定，不碰下一层。

层	回答什么	到位判据
L1 产品定义	这是什么产品、给谁、解决什么问题	一句话说清"谁因为什么离不开它"
L2 功能边界	做什么、不做什么、先后	每个功能能挂回产品定义的某一句
L3 数据流和模型	数据从哪来到哪去；实体、关系、必填	每个实体有唯一 owner；必填/可空定死
L4 交互和展示	用户怎么操作、状态怎么变	每个界面的前置/后置状态明确
L5 视觉和设计	长什么样	设计稿可直接作为需求源，无歧义

这个顺序有两个关键含义：

第一，视觉在最后，不在最前。 常见错误是先出视觉稿再倒推数据模型——等于先画皮肤再决定骨头长在哪。设计稿能当"唯一需求源"的前提，是 L1–L4 已定稿；否则设计稿本身就是摇摆的，以它为源只会放大摇摆。

第二，数据模型在交互之前。 在我的产品里，录音归属、分身必填字段、speaker_map 都是后端依赖，界面只是表层。L3 没冻结就动 L4/L5，改一次界面就要陪着改一次数据。

C1. 晶体化：产品的第一种形态

晶体化 = 按五个层次设计出来的产品：结构固定，部署之后，不会自我进化。

注意这个定义是中性的。晶体化不是缺陷，是所有产品的第一种形态：结构确定、可验证、可交付、可评审。它的局限是部署即定型，之后一切改进都靠人推着走。它真正的风险是被误认为终点——很多团队交付了晶体，就宣布"做完了"。

落地过程：从核心架构到具体功能

五层定稿 = 核心架构冻结。从架构到功能四步走：

1. 架构 → 功能分解：每个功能必须能挂到架构的确定位置——属于哪一层、动哪些实体、走哪条数据流
2. 功能 → 落地单元：一个功能 = 一次语义完整提交 = 一个可验证改动
3. 定顺序：先核心链路（端到端跑通），再边缘功能
4. 挂不上去的功能 → 回炉：挂不上架构 = 架构有洞，回五层补，不绕过去硬写——绕过去的每一行代码都是以后的返工

V. 验证分层：自动测试是地板，人工验收是天花板

这是我和 AI 协作中最容易翻车的地方。AI 交付代码后说"做完了"，但它的"做完"往往只是语法检查通过。验证其实有四层：

层	手段	能验证	不能验证
V1 静态与自动测试	语法检查、单测、集测	程序没写错	做对的事
V2 真实环境跑通	浏览器跑完整流程、真实数据跑后端	链路通、集成正确	体验和价值
V3 人工功能验收	人按验收标准逐项过	符合需求定义	真实场景表现
V4 一线用户验收	真实用户使用 + 评分反馈	价值成立	——

两条规则：层级不可跳——V1 不过不进 V2；但过了低层也不能宣称完成——V1 全绿只说明"没写错"，完成的标准在 V3/V4。我那笔"只做了语法检查"的债，就是停在了 V1。

C2. 生命化：种子 + harness + 自我迭代

晶体化之后，产品要获得生命。生命化不是"继续加功能"，它有三个明确的组件，缺一不可：

组件	含义	判据
种子	行业底层规则、边界——系统的基因	种子写的是规则不是功能：功能会长歪，规则不会
harness	让系统能跑、能被观察、能被评估、能换部件的运行环境	任意一次迭代的结果能被度量、被比较、被回滚
自我迭代	系统基于反馈持续改进自身，不靠人推	每一轮迭代有可判定的"更好"

为什么种子是"行业底层规则和边界"？ 规则决定进化方向——没有规则约束的自我迭代会漂移到奇怪的地方；边界决定安全——尤其在咨询、心理健康这类领域，"不能做什么"比"能做什么"更重要。

这也解释了一个很多团队搞错的事情：合规不是上线前的检查项，而是种子的一部分。在我的产品里，录音保留期限、风险线索规则、语音演练是否接真实语音——这三项必须在做数据模型之前就定下来。晚定，改的不是代码细节，是数据流和种子的基因。

晶体化与生命化不是两个产品，是同一产品的两个阶段：没有晶体做底子，生命化是失控的生长；没有生命化接续，晶体是漂亮的标本。

D. 一线迭代回路：把反馈做成产品的一部分

最后一段，也是整套方法里我最看重的一段。

到一线去跟真实用户碰撞——服务质量不在文档里，在真实使用场景里。但比"去一线"更重要的是：把反馈机制做进产品里。

以我的 AI 督导师产品为例。AI 会给咨询师的咨询记录写批注，老师（督导师）判断批注质量。我们有一张批注质量评分表，五个维度：

• 准确性——批注说得对不对
• 核心理由——有没有点出真正的原因
• 可操作性——建议能不能落地
• 语气——表达方式是否合适
• 使用意愿——老师愿不愿意真的用这条批注

所谓"五维评分表产品化为反馈入口"，就是把这张表做成产品界面里的一个组件：老师每收到一条 AI 批注，可以顺手按五个维度打分，分数直接进数据库——而不是事后发问卷、做访谈。

	传统做法	产品化反馈
反馈获取	事后访谈、主观抽样	每次使用即时产生
质量判断	凭感觉	五维可量化
改进依据	个别案例	趋势数据
迭代方向	拍脑袋	哪个维度低改哪个

这条回路一旦闭合，整套方法就活了：一线反馈 → 五维评分数据 → 自我迭代 → 新版本 → 再回到一线。这是全图唯一的一条回路，其余全部是单向依赖。它就是"自我迭代"组件的燃料来源——没有它，生命化只是口号。

可落地的三张清单

开工前：工作区干净；指定唯一需求源和任务源；L1–L5 定稿、L3 无"待定"；种子三要素（行业规则、边界、评估标准）明确。

落地中：每个功能挂得上架构，挂不上就回五层补；每次改动一次语义完整提交，决定写进 CHANGELOG；验证逐级过，不许停在 V1 宣称完成；参考物必带一句说明。

上线后：harness 就位（迭代结果可度量、可比较、可回滚）；评分表已产品化；迭代前先看评分趋势，哪个维度低改哪个。

写在最后

这套方法没有一条是发明出来的，全是踩坑踩出来的。AI 协同开发放大了两件事：它放大了速度——所以结构不清的代价来得比以往任何时候都快；它也放大了纪律的回报——因为 AI 是最忠实的执行者，你给它晶体般确定的结构，它就还你晶体般确定的实现。

从骨架到生命：先把产品做成一块结构确定的晶体，再给它种子、harness 和自我迭代的能力，让它活过来。

作者：陈盖盖，念影科技创始人，正在做 AI 认知穿戴与 AI 督导师产品。本文基于与 AI 结对开发的真实复盘整理。

JOTO 企业落地观察

• 企业若将“晶体化”作为 AI 服务交付起点，需同步预置“种子”规则——如金融场景的数据脱敏策略、医疗场景的诊断边界声明，这些必须在 L3 数据模型设计前固化，否则后期改造将牵动全链路。
• 验证分层中的 V3（人工功能验收）与 V4（一线用户验收）之间存在典型断点：多数企业尚未将 V4 的评分维度（如准确性、可操作性）内嵌为产品界面组件，导致反馈仍依赖离线问卷，无法支撑实时自我迭代。
• “harness”能力对企业而言不仅是技术基建，更是治理接口：它要求每次模型/逻辑迭代结果具备可度量、可比较、可回滚的元数据，这对 RAG 知识更新、智能体行为调优等场景构成刚性前提。
• 一线迭代回路的有效性高度依赖反馈入口的“零摩擦”设计——当评分动作需跳出当前工作流、另开表单或切换系统时，该回路实际失效；只有将五维评分深度耦合至用户原生操作路径，才能持续供能生命化演进。