企业官网建设流程全解析

1. 从"写代码"到"写意图"：AI原生SDLC到底改了什么

这两年大家都在聊AI编程，但多数讨论还停留在"用Copilot补全几行代码"的层面。真正把AI当成研发流程的一等公民之后，你会发现一个反直觉的事实：最难的从来不是让AI写代码，而是让AI准确理解你到底想要什么。Anthropic提出的六阶段重构手册，核心价值就在于它把"意图表达"这件事从隐性变成了显性，用一个叫intent.md的文件把需求、约束、验收标准全部固化下来，再配合持续评测机制，让AI在整条软件开发生命周期（SDLC）里始终不跑偏。

我最初接触这套方法论的时候，第一反应是"又一个流程规范"。但实际跑了两三个项目之后才意识到，它解决的恰恰是AI编程最要命的痛点：上下文漂移。你让AI改一个函数，它顺手把隔壁模块也重构了；你让它加个日志，它给你换了一套日志框架。这些问题的根源不是模型能力不够，而是你从来没有把"边界"和"意图"讲清楚。intent.md就是干这个的。

这篇文章我会把六阶段拆开讲透，重点落在intent.md怎么写、持续评测怎么落地、以及我在实操中踩过的那些坑。适合已经在用AI辅助开发、但总觉得"AI不听话"的工程师，也适合想给团队建立AI原生研发规范的Tech Lead。读完你应该能直接在自己的项目里跑起一套最小可用的流程。

2. 六阶段重构手册的骨架：每个阶段到底在解决什么问题

2.1 为什么是六个阶段而不是三个

很多人会问，SDLC不就是需求、设计、开发、测试、部署吗，为什么要拆成六个？我一开始也觉得是过度设计，直到我把Anthropic的六阶段和传统五阶段做了个对照，才发现多出来的那一个阶段恰恰是关键。

传统流程里，"需求"和"设计"是混在一起的，产品经理写个PRD，工程师看完直接开干。但在AI原生流程里，意图（Intent）和规格（Spec）必须分开。原因是AI对模糊描述的容忍度极低——你说"优化一下性能"，它可能给你加缓存，也可能给你改算法，还可能把异步改成同步。所以六阶段的第一阶段专门用来沉淀意图，第二阶段才把它翻译成可执行的规格。

我整理了一张对照表，方便你理解每个阶段的输入输出：

这张表我贴在团队白板上贴了三个月，新人来了先看这个，基本半天就能理解整套流程在干嘛。

2.2 阶段一到阶段二：意图和规格的边界在哪里

这是最容易混淆的地方。我的经验法则是：意图回答"是什么和为什么"，规格回答"怎么做和怎么验"。

举个例子。业务方说"用户反馈搜索太慢"。这句话进不了intent.md，因为它太模糊。经过意图捕获阶段，我们把它写成：

## 意图：提升搜索响应速度 - 目标：P95延迟从800ms降到200ms以内 - 约束：不引入新的外部依赖，不改动现有索引结构 - 非目标：不做搜索相关性优化，不做UI改动 - 验收：在10万条数据的测试集上，P95延迟达标

注意这里的"非目标"极其重要。AI最大的问题不是做不好，而是做太多。你明确告诉它"不做相关性优化"，它就不会去动排序算法。这一条我踩过坑：早期没写非目标，结果AI为了"提升搜索速度"，把相关性排序给简化了，速度是快了，但搜索结果质量暴跌，被业务方骂了一顿。

到了规格阶段，才把上面的意图翻译成技术方案：用哪个缓存层、索引怎么建、压测怎么做。规格是可以被AI直接执行的，意图不行。

2.3 阶段三到阶段四：上下文装配是被低估的环节

大部分团队跳过阶段三直接让AI写代码，这是效率最低的做法。我做过对比实验：同一个需求，直接丢给AI和先装配上下文再丢给AI，代码一次通过率差了将近40%。

上下文装配的核心是只给AI需要的，不给它可能乱用的。具体做法是：

• 把相关的文件路径、函数签名、数据结构整理成一个context.md
• 明确标注哪些文件可以改，哪些只能读
• 附上项目里已有的相似实现作为参考范例

我通常会用一段脚本自动生成这个上下文包，把intent.md、spec.md和代码库里的相关片段拼在一起。这样AI拿到的信息是精准的，不会因为看到无关代码而"手痒"去改。

3. intent.md 的写法：一份能落地的模板和三个真实案例

3.1 为什么intent.md不能用PRD代替

PRD是给人看的，intent.md是给AI看的。这个区别决定了它们的写法完全不同。PRD可以有大段的背景描述、用户故事、竞品分析，但intent.md必须是结构化的、无歧义的、可验证的。

我见过有团队直接把PRD丢给AI当intent用，结果AI把"提升用户体验"理解成了重写整个前端。问题就出在PRD里的形容词太多，AI没法判断边界。

intent.md的黄金法则是：每一句话都要能被验证。"提升用户体验"没法验证，"首屏加载时间小于1.5秒"可以验证。前者是PRD语言，后者是intent语言。

3.2 一份我用了半年的intent.md模板

下面这个模板是我从三个项目里迭代出来的，直接可以抄：

# Intent: [功能名称] ## 背景 [一句话说明为什么要做这件事，不超过50字] ## 目标 - [可量化的目标1] - [可量化的目标2] ## 约束 - [技术约束：不能引入什么、不能改动什么] - [业务约束：不能影响什么功能] ## 非目标 - [明确不做什么1] - [明确不做什么2] ## 验收标准 - [ ] [可自动验证的标准1] - [ ] [可自动验证的标准2] ## 相关上下文 - 参考实现：[文件路径] - 相关文档：[链接或路径]

这个模板的关键在于"非目标"和"验收标准"两节。前者防止AI过度发挥，后者让持续评测有据可依。

3.3 三个真实案例：从模糊需求到精准意图

案例一：给订单系统加一个超时取消功能

模糊需求是"订单太久没支付就取消"。我把它写成：

## 目标 - 订单创建后30分钟未支付自动取消 - 取消后释放库存，发送通知 ## 约束 - 不改动现有订单状态机 - 复用现有的消息队列，不引入新中间件 ## 非目标 - 不做退款逻辑（未支付订单无退款） - 不做用户主动取消的改动 ## 验收标准 - [ ] 创建订单31分钟后状态变为cancelled - [ ] 库存数量在取消后1秒内恢复 - [ ] 通知消息成功入队

案例二：优化一个慢查询接口

这个案例让我印象最深，因为AI差点把整个数据层重构了。加了非目标之后才收敛：

## 非目标 - 不改变接口的返回结构 - 不引入缓存层（本次只做SQL优化） - 不修改数据库表结构

案例三：给后台加一个数据导出功能

这个案例的坑在于数据量。AI默认写了个全量查询，直接把内存打爆。后来在约束里加了"必须分页导出，单次不超过1000条"，问题解决。

4. 持续评测：让AI的产出始终对齐意图

4.1 为什么一次性测试不够

传统测试是"写完代码跑一遍"，但AI原生流程里，代码是持续生成的，意图也可能迭代。如果只在最后测一次，你根本不知道是哪次改动引入了偏差。

持续评测的核心思路是：把intent.md里的验收标准转成自动化测试，每次AI产出代码都跑一遍。这样偏差在第一时间就被发现，而不是等到上线前。

我现在的做法是，每写一条验收标准，就同步写一个测试用例。这两件事必须一起做，否则验收标准就是空话。

4.2 把验收标准转成评测集的实操方法

具体怎么转？我拿案例一举例。验收标准是"创建订单31分钟后状态变为cancelled"，对应的测试可以这样写：

def test_order_auto_cancel_after_30min(): order = create_order() # 模拟时间推进31分钟 with freeze_time("2024-01-01 00:31:00"): run_cancel_job() assert order.status == "cancelled" assert get_stock(order.sku) == initial_stock + 1

关键在于时间要可控。用freeze_time这类工具把时间冻结，测试才能稳定复现。我早期没用时间控制，测试跑一次要等半小时，根本没法持续跑。

评测集的组织方式我推荐按意图分组：

evaluations/ intent_order_cancel/ test_timeout.py test_stock_release.py test_notification.py intent_search_speed/ test_p95_latency.py

这样每次改动某个意图相关的代码，只跑对应的评测集，速度快，定位准。

4.3 评测报告怎么读：三个关键指标

跑完评测不能只看"通过/失败"，我通常关注三个指标：

• 通过率：直接反映意图满足程度，低于100%就要查
• 偏差类型：是功能没实现，还是实现了但越界了
• 回归数量：本次改动导致多少原有测试失败

偏差类型这个指标特别有用。如果AI总是"越界"，说明intent.md的非目标写得不够狠；如果总是"没实现"，说明目标描述不够具体。根据偏差类型反推intent.md的改进方向，这是持续评测最大的价值。

5. 反馈回流：让intent.md越用越准

5.1 偏差不是bug，是intent.md的改进信号

很多人把AI产出偏差当成"AI不行"，其实大部分时候是intent.md没写清楚。我现在的习惯是：每次评测发现偏差，先不改代码，先改intent.md。

比如有一次AI给一个接口加了限流，但intent.md里没提限流。这算越界吗？严格说算，但仔细想想，限流其实是合理的。于是我把它写进了intent.md的约束里，下次AI就会主动加。这就是反馈回流。

5.2 一个季度迭代下来的intent.md长什么样

我手上有个项目跑了三个月的AI原生流程，intent.md从最初的20行涨到了80行。多出来的60行几乎全是"非目标"和"边界条件"。这些内容不是一开始能想到的，都是被AI的偏差"教"出来的。

这个过程有点像带新人。新人第一次做错，你告诉他边界在哪；第二次做错，你再补充一条。几次之后，他就知道分寸了。AI也一样，intent.md就是它的"分寸手册"。

5.3 团队协作中intent.md的版本管理

intent.md必须进版本控制，而且要和代码一起review。我见过有团队把intent.md放在共享文档里，结果代码改了intent没改，评测跑出来的结果和实际意图对不上。

我的做法是：intent.md和对应的代码放在同一个PR里。改代码必须同步改intent，否则PR不通过。这条规则执行了两个月，团队的意图表达质量明显提升。

6. 实操中踩过的坑和几条硬经验

6.1 坑一：intent.md写太细，AI反而不会干活

我一开始走极端，把intent.md写得像伪代码，结果AI完全不动脑子，就照着字面翻译，遇到没写到的边界情况直接崩。后来我调整了粒度：意图层面写清楚，实现层面留空间。比如"用缓存优化查询"就够了，不用写"用Redis的String类型存JSON"。

6.2 坑二：评测集维护成本被低估

持续评测听起来很美，但评测集本身是要维护的。意图变了，评测要跟着变；代码重构了，测试可能要调整。我建议初期只对核心意图做持续评测，边缘功能还是用传统测试。全量持续评测的维护成本，小团队扛不住。

6.3 坑三：把AI当执行者而不是协作者

这是心态问题。如果你把AI当成一个只会听指令的工具，intent.md就会写成命令清单。但AI其实更像一个需要理解上下文的协作者，intent.md应该写成"背景+目标+边界"的组合。心态变了，写法就变了，产出质量也跟着变。

6.4 三条我现在的硬规则

• 规则一：任何AI生成的代码，必须能追溯到某条intent。追溯不到的，要么补intent，要么删代码。
• 规则二：intent.md的每次修改都要有理由，理由来自评测偏差或业务变化，不能凭感觉改。
• 规则三：新项目第一周不写代码，先把intent.md和评测集搭起来。磨刀不误砍柴工，这一周能省后面一个月。

这套流程我跑了半年，最大的感受是：AI原生SDLC不是让AI替你做决定，而是逼你把决定想清楚。intent.md写明白的那一刻，其实需求就已经想透了，AI只是帮你把它变成代码。持续评测则是那道保险，确保想清楚的东西真的被做出来了。至于工具选型、模型选择这些，反而是最不重要的——流程对了，换哪个模型都能跑。