企业官网建设流程全解析

前阵子帮一个做 SaaS 的团队做技术咨询，他们年初就接入了 Claude Code，结果三个月过去，研发效能不升反降——百分之四十的 PR 会被 reviewer 打回重做。问题不是模型不够强，而是他们还在用二十年前的流程组织一个全新的生产力工具。这个场景我想很多人并不陌生。

最近社区里讨论最多的 AI 原生 SDLC，Anthropic 那本六阶段重构手册，恰好就是在回答这个事。它不叫方法论，叫“重构手册”，核心主张不是“给传统流程加 AI”，而是“按 AI 的能力重新设计流程”。整本手册里，有两个东西让我觉得最值得落地：一个是作为项目唯一事实源的 intent.md，另一个是把评测贯穿始终的持续评测机制。这篇文章把我实际拆解和应用的经验完整写出来，包括六个阶段怎么走、intent.md 怎么从零写起、持续评测怎么接入 CI，以及我在落地过程中踩过的三次真实报错和意图漂移问题。如果你正准备在团队里推 AI 原生开发，这篇应该能帮你省掉几周自己摸索的时间。

1. 从“给流程加 AI”到“按 AI 重写流程”：Anthropic 六阶段手册到底想改变什么

1.1 为什么“AI 辅助”路线会卡住

先说个反直觉的结论：把最强模型塞进传统 SDLC，效果往往是负的。

我给那个 SaaS 团队做诊断的时候，发现他们的典型工作流是：产品经理写 PRD，技术经理拆分任务，工程师领任务后打开 Claude Code 写代码，写完提 PR，reviewer 看不懂 AI 生成的 diff，打回重改，改完再提。整个链路里每个环节都“有 AI”，但没有任何一个环节是“为 AI 设计的”。结果就是 AI 每十分钟产出一个 PR，人类每两小时才能 review 完一个。瓶颈从“写代码”转移到了“审代码”，效能反而更差了。

这就像把 F1 引擎装进马车车厢——引擎是快的，但车架、悬挂、驾驶员的操作方式全都跟不上。

1.2 六阶段到底长什么样：从 Plan 到 Maintain

Anthropic 那本手册给出的方案，是把整个软件交付流程重构成六个阶段：Plan（规划）、Design（设计）、Develop（开发）、Test（测试）、Deploy（部署）、Maintain（维护）。我把它理解成一个螺旋结构，而不是传统的瀑布。六个阶段的职责分配，我用自己的话整理成了一张表：

这个表的要点在于：每个阶段都是“人定意图、AI 执行、人做裁决”，而不是“人下命令、AI 照做”。区别很微妙但很关键。

1.3 为什么这套框架对中小团队反而更现实

聊到这里有人会问：这套流程听着很好，但那是为大公司设计的吧？我的看法正相反。六阶段重构对中小团队反而更友好，原因有三个。

第一，中小团队没有庞大的历史流程包袱。传统大厂在 SDLC 里沉淀了几十年的规范、审批流、合规检查，每一项都难改；而中小团队的流程几乎是一张白纸，重构成本极低。第二，中小团队的核心瓶颈恰恰是“人太少、事太多”，这正适合把执行类工作交给 AI。第三，中小团队的决策链路短，intent 的决策和更新不需要跨部门协调，一个十个人的小组完全跑得起来。我自己实践下来，这套东西对 5 到 50 人的技术团队是最舒服的甜点区。人数再少，光维护评测集就有点吃力；人数再多，组织协调的复杂度会反过来盖过收益。

2. intent.md 才是整个仓库的“宪法”：写什么、怎么写、谁有权改

2.1 intent.md 与 PRD、CLAUDE.md 的分工

聊六阶段之前，我先把这次拆解里最核心的产物说清楚：intent.md。

很多人第一次看到 intent.md 会问：这不就是 PRD 吗？还真不是。我把三者的分工用一句话总结：PRD 是写给产品看的“我们要做什么”、CLAUDE.md 是写给 AI 看的“你要遵守什么操作规范”、intent.md 是写给整个仓库看的“我们为什么要存在以及如何判断做得好”。

实际效果上，PRD 往往几千字写完就没人再看了；CLAUDE.md 太侧重操作细节，管不住“方向”；而 intent.md 的作用，是让任何人都能在一个文件里看到项目的“为什么”和“验收标准”，同时也让 AI 在每一次生成代码、跑测试、提 PR 的时候都有同一个参照系。

2.2 一个能直接复制的 intent.md 骨架

我结合自己的实践，给一个可以直接抄的骨架模板。这份模板的核心原则是：短、明确、可验证。不要写形容词，要写数据。

# Project Intent: 内部工单系统（示例） ## Why（为什么做） 这个系统是为了把一线运维的重复人工操作从每周 15 小时降到 5 小时以内。 它不是“一个工单工具”，而是“把人工操作自动化的平台”。 ## What（真实目标，不等同于功能清单） - 用户可以用自然语言创建工单，系统自动识别优先级 - 工单状态变化全程可追溯，任何操作留审计日志 - 每类工单的平均处理时长在接入手动流程后有可量化的下降 ## Non-goals（明确不做什么） - v1 不做审批流，审批逻辑留在线下 - v1 不做移动端适配 - 不做 AI 自动处理工单内容，只做自动分拣和流转 ## Constraints（约束条件） - 技术栈：Node.js 22 + React 18 + PostgreSQL 15 - 部署：单机 Docker Compose，v1 不上 K8s - 团队规模：2 名后端、1 名前端、1 名产品兼职 ## Quality Bar（可验证的验收标准） - 工单创建接口 P95 延迟不超过 1 秒 - 审计日志覆盖率达到 100%，不允许出现无记录的变更 - 内置评测集 eval/ 中所有 case 通过率 100%，后续 AI 改动不得引入 API 行为回归

注意看，这个模板里我没有写“要做一个友好的界面”“要保证系统稳定”这类废话。所有可验证项都是可检测的。这就是 intent.md 的生命力所在：它天生是一份可以被机器执行的测试契约。

2.3 迭代纪律：什么时候改、谁来改

intent.md 最容易被忽视的问题，是改动权限。

我见过一个团队，把 intent.md 放进了仓库里，然后 Claude 每次跑任务的时候都会“自作主张”往里面补充内容。两周之后，那个文件从一百行膨胀到了两千行，核心的 Why 反而淹没在各种细节里，没人再看了。

我后来定的纪律是：

• intent.md 的修改必须走人工 review，并且我建议把这条规则写进 CI 的 CODEOWNERS 里，任何不经 review 的改动直接阻塞合并。
• AI（包括 Claude）只有建议权，没有直接修改权。它在任务中发现 intent 需要更新，应该提一个修改建议，由人来落地。
• 每周做一次 intent review，只问三个问题：这周我们有没有偏离 Why？评测集里有没有过期用例？下周最可能出错的是哪一段？

这条纪律刚定的时候团队觉得“多此一举”，跑了三周之后所有人都真香了——因为再也没有人需要在一堆变形的措辞里去猜“项目到底要什么”。

3. 六阶段逐段落地：从 Planning 到 Maintenance 的 AI 工作流走法

3.1 Planning 与 Design：把模糊目标变成可评测的意图

Planning 阶段最容易犯的错误，是让 AI 直接生成需求文档。错了。AI 在 Planning 阶段最擅长的是“出选择题”，而不是“写作文”。

实际操作我一般这样走：把一个模糊的业务目标丢给 Claude，让它产出三样东西——候选用户故事列表、每类用户的验收标准、明确不做的清单。然后人要做的是划掉不合理的项，调整优先级，把这个结果固化进 intent.md 的 What 和 Non-goals。

例如前一段时间我们做一个“报表导出”功能，业务方的原话是“能不能把后台数据导出来方便运营看”。我把这句话丢到 Claude，它生成了 12 个候选用户故事，其中包括“支持按渠道维度筛选后导出”“导出任务失败时自动通知创建人”等等。其中“自动通知创建人”这个点，业务方聊需求时完全没想到，但实际是导出失败后支持人员最痛的场景。这就是 AI 在 Plan 阶段的价值——不是替你拍板，而是帮你把没想到的选择项摆到桌面上。

Design 阶段同理。我现在的做法是：让 Claude 给出两三个技术方案，每个方案附带“选它的理由”和“不选它的理由”，最后人只需要做决策。决策的本质是取舍，而取舍的依据在 intent.md 里已经写清楚了——约束条件和 Non-goals 就是天然的裁量标准。举个例子，constraints 里写了 v1 不上 K8s，那任何需要 K8s 才能跑顺的设计方案，直接砍掉不需要讨论。

3.2 Develop 与 Test：Agent 写代码、人写评测

到了 Develop 阶段，我的体会是：这个阶段反而是六个阶段里最短的，也是最不该花太多精力的。因为 AI 写代码的速度非常快，真正的瓶颈在 Test。

我这里想纠正一个常见误区：让 AI 写测试不是“偷懒”，而是“把人的精力留给判断”。传统开发里，人写完功能还要写测试，测试是为了证明功能正确；但在 AI 原生开发里，人是通过“定义什么算坏”来间接控制 AI 的——这就是评测集的意义，我会在下一章详细展开。

举一个真实的例子。我们在做一个 PDF 解析服务时，Claude 在 Develop 阶段生成了一版核心解析代码，附带 15 个单元测试。这些测试在它自己看来全绿，但合并后第一周就收到了两起客户反馈：断行文本被错误合并、加密 PDF 没有提示用户。原因就是它生成的测试用例过于“理想化”，全用的是标准输入，没有覆盖真实世界的脏数据。

后来我们在 Test 阶段做了一件事：把评测集里加进了“脏数据专项”用例，包括不规则空格、表格混排、扫描件缺页、密码保护文件。从那次之后，AI 生成的代码再也没在这几个问题上翻过车。这个教训我复述一遍：AI 生成测试的盲区，要用人类定义评测集来补齐。你不可能让 AI 替你想清楚所有“坏”的样子，但你可以把已知的“坏”全部喂到评测里。

3.3 Deploy 与 Maintenance：AI 不是只管到合并

很多人以为 AI 原生开发到 PR 合并就结束了，其实手册里 Deploy 和 Maintain 阶段才是拉开差距的地方。

Deploy 阶段我现在的流程是：代码合并进 main 之后，CI 自动出发一个部署任务，Claude 会基于 git log 和评估报告自动生成一份发布说明，内容包括本次变更的行为影响、需要关注的指标、以及它建议的灰度比例。然后人做发布决策。这个流程听起来轻巧，但有一个前提——你必须在 CI 里把“变更影响”这个信号做出来，否则 Claude 写出来的发布说明就是套话。

Maintain 阶段更值得重视。传统团队线上出问题了，第一反应是查日志、找代码、定位根因；AI 原生团队的 Maintain 阶段，是把线上数据拉回评测集里，让 AI 分析“这是评测集的盲区还是代码真的改坏了”。

举个实例：我们有个服务的错误率从 0.1% 涨到 0.4%，人肉排查一小时没结果，我把最近的监控数据和相关代码 diff 丢给 Claude Case 分析，它在三分钟内指出是某个异常类型在上游 API 增加字段后没有被正确兼容，并给出修复建议和两条需要补进评测集的回归用例。那次之后，我对 Maintain 阶段的定位就从“救火”变成了“扩军”——每次线上问题的产出，不只是修复代码，还有一个新的评测用例。

4. 持续评测不是跑一遍测试那么简单：评测集、分数门禁与指标陷阱

4.1 评测集的三层构成：回归、意图对齐、红队

持续评测是 AI 原生 SDLC 里和 intent.md 并列的另一根支柱。如果说 intent.md 定义了“方向”，评测集就是定义“什么叫没跑偏”。

我实践的评测集分为三层：

以我的经验，一个小型项目的评测集可以从 20 到 50 条起步，之后不要盲目追求数量，而应该每一条都问自己：“如果这条用例挂了，用户真的会感知到吗？”如果答案是不会，这条用例就该删掉或重写。

4.2 把评测结果做成合并门禁

评测集建好之后，最关键的落地动作是把它接进 CI。我给一个 GitHub Actions 的示例，这个配置是我实际在用的，逻辑非常简单：每次 PR 触发评测任务，分数必须超过基线分数才允许合并。

name: evals on: pull_request: branches: [ main ] jobs: eval: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 22 - run: npm ci - run: npm test - run: npm run eval env: ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

注意那个npm run eval，它背后跑的逻辑是：读取当前分支的代码，执行评测集，把结果和基线分数对比。这里有一个实测中很重要的细节——阈值要设成“允许小波动，禁止大倒退”，比如基线是 90 分，可以容忍 88 到 90 之间的小波动（可能只是并发抖动），但低于 85 分就必须阻塞合并。因为评测集本身也会有噪声，阈值设得太死，CI 会天天报红，最后大家就不看 CI 了。

4.3 那些看起来很漂亮、实际会骗人的指标

这部分是我最想提醒的，因为评测落地时最容易掉进指标陷阱里。

第一个陷阱是pass@k 套用到长任务上会失真。pass@k 衡量的是“生成多个候选，其中有没有一个能通过测试”，这在短小的代码补全场景下有效；但 AI 原生 SDLC 里，任务是端到端的——让 AI 修改一个服务、补测试、改文档，你不可能让同一个任务跑五次看哪次成功。所以不要照搬论文里的评估指标，而是要定义“任务完成度”评分，我一般用功能行为是否达成、是否有回归、以及代码规范三个维度打分。

第二个陷阱是让模型给模型打分。如果你的评测逻辑是“把输出丢回给 Claude 问它写得好不好”，那你得到的分数的可信度是很低的——模型对自身输出的偏好偏差大得惊人。我踩过这个坑，一开始图省事用 Claude 自评，结果所有输出全是 95 分以上，完全失去了区分度。后来改成独立编写 checker，每个检查项是硬性的规则判断（比如断言某个错误信息是否出现、某个接口是否返回预期状态码），才真正可用。如果要用模型做评估，至少要让另一个 Prompt 完全独立的模型当评委，且给它提供明确的行为契约。

第三个陷阱是用 token 消耗量或覆盖率当质量指标。token 消耗衡量的是成本，不是效果；代码覆盖率衡量的是“哪些行被跑过”，不是“这些行为是否符合预期”。这两个指标可以作为参考，但永远不要作为合并门禁。我见过团队为了把覆盖率从 70% 刷到 90%，生成了大量毫无断言的桩测试，质量反而下降了。

5. 落地过程中的真实报错和长上下文失控：三次踩坑记录

5.1 unable to connect to anthropic services：从网络到密钥的排查顺序

第一次把我们整个 AI 原生流程卡死的，是 CI 里突然大面积报unable to connect to anthropic services failed to connect to api.anthropic.com。当时第一反应是 API 挂了，但实际排查下来发现根因根本不是这么回事。

我把排查顺序固化成一套 checklist，现在再遇到这个报错，两步之内就能定位：

• 先看网络链路的出口。很多公司 CI Runner 在隔离网络环境里，出公网要走企业的 HTTPS 代理。这时候需要检查环境变量里HTTPS_PROXY是否配置正确、NO_PROXY是否错误地把 API 域名也拦进去了。
• 再看 API Key 本身是否有效，可以用一个最简单的 curl 测试通不通。注意如果公司用的统一 LLM 网关（比如 LiteLLM、Kong），那要检查的就不是 Anthropic 原站 key，而是网关的认证配置。

这类问题之前我们还遇到过一次非常隐蔽的坑：CI 里的环境变量被某个依赖装成了无效的空字符串，导致运行时读取到的不是 key 而是空白，所有请求全部 401，日志里看到的提示却是“connection error”。所以我的建议是，检查的顺序永远是“链路通畅性优先，密钥有效性次之”，因为密钥问题通常有更明确的 401/403 状态码，而断连问题往往是黑的，没有状态码可看。

5.2 expected a gateway model route：模型名与路由配置的错位

第二个报错doesn’t look like an anthropic model: expected a gateway model route是我们接入企业统一网关时遇到的。这类错误文字看起来很深奥，实际原因非常简单：代码里请求的模型名，和网关路由表里注册的模型名对不上。

我们的架构是：CI 里的请求统一走 LiteLLM 网关，然后由网关转发到 Anthropic API。配置文件里注册的模型名和代码里引用的模型名差了一位版本号，比如代码里写的是claude-sonnet-4，但网关里注册的是claude-sonnet-4-20250514这个带日期的完整版本名，网关匹配不到路由，就报出了这个提示。

修复方法也很简单，在网关配置里同时注册“别名”和“具体版本”两个模型名，业务代码里统一用不带日期的别名，这样后续模型更新时不用改业务代码。

# LiteLLM 网关配置示例 model_list: - model_name: claude-sonnet-4 litellm_params: model: anthropic/claude-sonnet-4-20250514 api_key: os.environ/ANTHROPIC_API_KEY

这个错误给我们的教训是：AI 原生工作流里，模型名是基础设施的一部分，它应该像数据库连接串一样被集中管理，而不是散落在各个脚本里。只要把“业务侧用别名、网关侧管版本”这个原则定下来，这类报错基本不会再出现。

5.3 意图漂移：AI 把 intent.md 越改越厚

第三个坑，其实比任何 API 报错都更隐蔽——意向漂移。

前面提到过，intent.md 如果不设权限，AI 会每次迭代都往里加内容。我经历的真实情况是：一个内部数据分析平台的 intent.md，第六周的时候达到了历史峰值 1800 行，其中至少有 60% 的内容来自 AI 自己在完成任务时“合理化”的补充。比如它加了一段“本项目的未来方向是AI自动生成报表”，这件事我们团队压根没讨论过，但它似乎很有道理。

这个问题的根因是：AI 的上下文窗口有限，一旦 intent.md 本身太长，它就会“挑重点”读取，而那些被跳过的部分，恰恰可能是之前的核心约束。结果就是项目方向在人没有参与的情况下悄然改变——这就是意图漂移。

我的解法分三层：

第一层是结构隔离。intent.md 只保留最核心的 Why、What、Non-goals、Constraints、Quality Bar 五块内容；其他所有细节（技术方案、会议记录、架构决策记录），全部拆到 docs/ 目录下单独维护，intent.md 里只留一行链接。

第二层是顶层锁定。在文件头部放一个“不可变更的核心意图”段落，并在 CODEOWNERS 里设置为只有 Tech Lead 和产品负责人可以修改。AI 可以建议变更，但任何自动变更都会被 CI 直接拦截。

第三层是本地对照。每次在 Develop 阶段开始前，要求 Claude 先将当前 intent.md 的核心内容读一遍，并在输出里复述“本项目 v1 不做 X、核心约束是 Y”，这样可以强制上下文不漂移。实测这招非常有效，它相当于给 AI 一个“锚点”，阻止它从上下文深处掏出过期记忆。

6. 团队与角色：AI 原生模式下工程师到底在做什么

6.1 从“写代码的人”到“定义意图的人”

最后聊一个绕不开的话题——这个流程落地之后，工程师的角色到底变成了什么？

我的直接观察是：最值钱的技能从“写代码快”变成了“定义意图准”。传统开发里，工程师的核心产出是代码；AI 原生开发里，工程核心产出是“告诉 AI 你要什么、定义什么叫做好、审查 AI 是否做对了”。代码本身反而成了中间产物。

这带来了很多连带变化。QA 工程师变成了“评测工程师”，主要工作是设计评测集和分析失败用例；架构师变成了“约束工程师”，职责是写出能落进 intent.md 和 CLAUDE.md 的约束条件；普通开发者的核心技能变成了批判性阅读 diff——不是“这个代码风格符合规范吗”，而是“这段代码的实现是否忠于 Why”。

我记得有一次，开发组里一个新同学花了一整天训练 Claude Code 去写一个十分复杂的 SQL 存储过程，调了很多轮终于跑通了，但最后我们发现整个存储过程实现的东西，在 intent.md 的 Non-goals 里明确写着“v1 不做”。那一刻团队才真正明白：AI 把没人做的事做得再好，也抵消不了它做了“不该做的事”带来的返工成本。之后我们的 Development 流程强制加入一步：任何新功能开工前，先在 intent.md 里确认它不在 Non-goals 列表里。

6.2 试点项目的选择标准：什么样的仓库最适合先跑

如果你也想在团队里推这套流程，我的建议是不要一上来就把所有项目全切过去，而是先选一个“试点”。

我实践下来的筛选标准就三条：

• 这个仓库有足够的测试基线。如果连传统测试都没有，直接上评测集等于在流沙上盖楼。
• 模块边界足够清晰。领域边界模糊的项目，AI 很容易在 Develop 阶段越权修改无关模块，导致 review 成本飙升。
• 业务决策人愿意每周花 30 分钟看一次 intent diff。没有这条，intent.md 很快就会沦为僵尸文档。

我见过最快落地成功的案例，是一个 8 人的内部工具团队，从决定试点到第一版评测集接入 CI，只花了 8 天；我也见过大团队推这个东西推了两个月还在打架，原因是利益相关方太多，光是争论“intent.md 归产品还是归技术管”就吵了两周。所以如果你想推，别追求一步到位，找出一个小而关键的仓库，先把闭环跑通。

6.3 三个月内的实施路线图

最后给一个可以直接抄的实施节奏，我称之为“三个两”：

• 前两周：只做一件事，给仓库写上 CLAUDE.md 和 AGENTS.md，搞定最基本的 AI 操作规范。
• 第三到四周：写 intent.md 初稿，同时整理出第一版 20 条以上的评测用例，跑通评测脚本。
• 第五到第八周：把评测接进 CI，建立合并门禁，开始强制“未过评测不得合并”。
• 第八周以后：进入常态化迭代，每周做一次 intent review，每次线上事故修复就给评测集补充新的回归用例。

最后一个我个人的实操心得：评测集才是 AI 原生 SDLC 真正的“团队记忆”。它比 wiki 更精确，比代码注释更可执行，而且它天然和 CI 绑定在一起，没有人敢无视一个红灯。如果团队只能做一件事来向 AI 原生靠拢，我认为不是买最好的模型，也不是天天聊 Prompt 技巧，而是老老实实把那个“判断什么叫做好”的评测集建起来。有了它，六阶段和 intent.md 才是活的，没有它，一切 AI 原生流程都是纸面功夫。