企业官网建设流程全解析

当代码不再是瓶颈：AI-native SDLC 的六阶段实战

一份面向工程团队的实践指南：如何让 AI 参与从想法到生产、再回到下一次改进的每个阶段。

本文看点

01 代码不再是瓶颈 02 六阶段闭环 03 治理与审计

代码不再是瓶颈

过去一年，组织已经能用 AI 以难以想象的速度产出代码，但审批、交接、review 和政策并没有同步变快。Claude Code 带来的效率，常常被旧流程重新堵住。

传统软件开发生命周期（SDLC）把软件从想法带到生产拆成 Plan、Design、Build、Test、Deploy、Maintain 六段，每段由不同角色负责，再用文档、ticket 和签字把工作交给下一个人。这套流程诞生于“写代码最贵、最慢”的时代。

• Build 变快后，Plan、Test、Review 和 Deploy 仍按人的速度运行。

• 逐行人工检查 diff 无法应对 agent 生成的大量改动。

• 治理例外仍要排队等会议，成本因此上升。

— Build 不再是约束，真正拖慢交付的是周围仍按人工速度运行的步骤。

安全团队尤其容易成为新的瓶颈：他们的编制按人工产出设计，agent 一旦放大代码产量，review queue 就会堆积，或者代码在 review 不足的情况下上线。受监管组织不能接受这两个结果，所以 security 和 policy checks 也必须跟上 agent 的速度。

AI-native SDLC 不是取消控制，而是把旧控制目标换成更贴近现实的执行方式：流程从直线变成环，AI 嵌入每个节点，人类继续对需要判断的决定负责。

什么是 AI-native SDLC？

AI-native SDLC 不是把人从流程里拿掉，而是把原有的控制目标改造成能跟上 agent 速度的执行方式。流程不再是一条直线，而是一个由 artifact 驱动的 loop：每个阶段提交结果，下一阶段读取结果并被自动触发。

人类仍然对需要判断的决定负责，只是注意力从“盯着 agent 打字”转移到“审什么产物、在哪个 gate 做决定”。

传统 SDLC 与 AI-native SDLC

下面这张表不是非黑即白的二选一，而是两个端点。大多数团队会从其中一两项开始，逐步向右侧移动。

Plan

TRADITIONAL SDLC

需求靠委员会、workshop 和签字确认，再手写成文档。

AI-NATIVE SDLC

Claude 从原始信息中提炼痛点，写入人能读、agent 能执行的 intent.md。

Design

TRADITIONAL SDLC

分析师写 spec，设计师再拆解。

AI-NATIVE SDLC

一次会话完成需求与设计，标准由 skills 固化并进入 git。

Build

TRADITIONAL SDLC

代码和测试手写，文档通常事后补。

AI-NATIVE SDLC

AI 生成代码与测试，组织知识沉淀在 CLAUDE.md 和 skills 中。

Test

TRADITIONAL SDLC

QA 在阶段边界设置闸门。

AI-NATIVE SDLC

Continuous evals 贯穿实现过程。

Deploy

TRADITIONAL SDLC

人工逐行 review，治理依赖周期性会议。

AI-NATIVE SDLC

agent 先处理常规 review，人类聚焦高风险判断，hooks 负责审批关卡。

Maintain

TRADITIONAL SDLC

人盯着线上报警和 bug。

AI-NATIVE SDLC

agent 监控生产，异常控制带会生成新的 intent.md，重新进入闭环。

贯穿右侧的主线，是每个阶段都会提交一个 artifact：intent.md、spec.md、plan.md、代码与测试、带 review 结论的 PR，以及 incident record。commit 链同时是审计轨迹：谁提出了什么、agent 产出了什么、谁批准了什么。

Plays：把六个阶段接成一个环

这份 playbook 把完整 SDLC 拆成六个非线性阶段：Plan、Design、Build、Test、Deploy、Maintain。每个 play 都说明改变什么、如何开始、怎样落地、治理风险是什么，以及如何衡量效果。

• 阶段结束时提交 artifact，并由这个 commit 触发下一阶段。

• 接受 intent.md 会触发需求与设计；批准 spec.md 会进入 plan mode；合并 PR 会触发 pipeline；生产控制带被突破会生成下一份 intent.md。

这些 play 可以按依赖关系逐步采用，不需要一次性重做所有流程。先手动跑通，再把稳定动作写成 slash command、skill、hook 或 CI job。

— 六个 play 不是线性接力，而是由 artifact 和触发条件连接起来的闭环。

02

PLAN

把想法变成 intent.md

先把 intent home 搭起来

平台或工程团队只需要做一次基础设施：建立共享的 intent home，确定谁可以写入。没有 git 经验的同事可以通过 GitHub connector 或 Cowork 让 Claude 代为提交 markdown；作者和时间戳仍然会进入记录。

任何需求都可以进入 Plan：一个人的想法、一张 ticket，或者生产事故触发的改进建议。发起人用自己的话描述问题、受影响的人、理想结果和边界，不需要先写正式 PRD。

Claude 负责追问范围、用户、约束和成功标准，并把对话整理成 proto-spec。最终产物是人能读、agent 也能继续处理的 intent.md。产品负责人必须在提交前校正误解，并决定接受还是退回。

执行清单

• 用自然语言描述问题，让 Claude 追问范围、用户和成功标准。

• 要求它按组织模板写入 intent.md，并标出未决问题。

• 发起人修正内容，产品负责人审核后提交；接受动作触发 Design。

intent.md

# Intent: claims status self-service

Author: J. Ortiz (claims operations). Status: draft.

## Problem

Customers phone the contact center to ask where their claim is.

Handlers spend roughly a third of call time on status-only queries.

## Proposed outcome

Customers see claim status, next step and expected date in the portal.

## Constraints

No new PII in the portal session. Existing authentication only.

治理依据就是已提交的 intent.md：作者、时间和修订历史都在 git 中，产品负责人作出接受或拒绝的判断。

03

DESIGN

让需求与设计在一次会话里收敛

intent.md 被接受后，Claude 根据组织的 brand、security、compliance 和 UX skills 生成 requirements and design spec。产品负责人审阅结果，但不再亲自把需求重写一遍。

产品负责人可以在 Claude Design（beta）里从 intent.md 生成 mock，迭代后再导出给 Claude Code 实现。政策不再等到数周后的 review 才被发现，而是在 spec 写作时作为约束生效。

spec、生成它的 Prompt，以及当时生效的 skill 版本都应该可追溯。这样政策是在 spec 写作时生效，而不是等到几周后的 review 才被发现。

执行清单

• 附上 intent.md，要求 Claude 生成完整 spec.md，并明确列出风险。

• 逐条核对 spec 是否解决原问题，先处理 flagged concerns。

• 把 spec.md 与 intent.md 一起提交；人工决定是否进入 Build。

Prompt

Read the attached intent.md and produce a requirements and design spec for integrating it into our existing codebase. Apply the skills available to you so the plan conforms to our brand guidelines, security policies and UX standards. Document the spec fully as spec.md, ready to hand to the engineering team.

04

BUILD

从 plan mode 开始，让实现可审计

工程师把已批准的 spec.md 交给 Claude Code，并默认从 plan mode 开始。Claude 先列出要改的文件、工作顺序、测试证据和潜在风险，工程师通过追问把计划打磨到“一个没看过对话的人也能照着实施”。

• 同时提供 intent.md 和 spec.md，追问破坏面、最高风险步骤及替代方案。

• 批准后提交 plan.md；实现偏离计划时，在同一 commit 中同步修改。

plan.md

# Plan: claims status self-service

## Files that change

portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py,

claims-api/tests/test_status.py

## Order of work

1. Add the status endpoint behind existing auth.

2. Panel against the endpoint.

3. Wire into the portal nav.

## Risks

The claims-core API rate-limits at 50 rps; the panel must cache.

CLAUDE.md、skills 与 hooks

CLAUDE.md 应该像给新同事的第一天手册：写清构建、测试、lint 命令、架构约定和常见坑。它进入 git，所有修改像代码一样 review。skills 承载组织知识；必须无例外遵守的政策，再由 hooks 做 deterministic enforcement。

CLAUDE.md

# Payments service

## Commands

- Build: make build

- Test: make test (unit), make itest (integration, needs docker)

- Lint: make lint (runs in CI; fix before pushing)

## Conventions

- Java 21, Spring Boot 3. No new Lombok.

- Money is always BigDecimal, never double.

- Every endpoint needs an integration test in src/itest.

## Things Claude gets wrong

- Do not bump dependency versions; the platform team owns them.

- The legacy v1/ package is frozen; changes go in v2/.

并行 session 使用独立 worktree；subagent 负责单一重复任务。工程师的职责从盯每一次编辑，转向拆任务、定边界、审结果。

auto mode：从盯编辑转向审 artifact

当 CLAUDE.md、skills、hooks 和测试闭环足够成熟后，可以从 plan mode 切换到 auto mode：工程师批准计划，Claude 连续执行编辑，不必每次改文件都重新确认。配合独立 worktree，多个 session 可以并行推进。

Legacy system 的 source of truth

在遗留系统里，CLAUDE.md 是新同事第一天需要读的上下文：构建、测试、lint、架构边界、冻结目录，以及团队最常踩的坑。可以先运行 /init 生成草稿，再删到只剩真正有用的内容。它应该短、稳定、可 review；过时内容会占用每次 session 的 context。

skills：把组织知识变成可执行规则

skill 适合承载安全标准、API 设计约定或品牌规范。它是一个带 frontmatter 的 SKILL.md，写清什么时候触发、具体要做什么，并随代码进入 .claude/skills/<name>/，或通过组织级 plugin 分发。

SKILL.md

---

name: secure-api-review

description: Apply the API security standard. Use whenever creating or

modifying an external-facing endpoint, reviewing API code, or

generating an OpenAPI spec.

---

# Secure API review

When you create or change an API endpoint:

1. Every endpoint requires the gateway JWT.

2. Validate request bodies against the OpenAPI schema.

3. Emit an audit event for state-changing endpoints.

4. Never put fields tagged pii into logs or errors.

skill 是 advisory control：它会提高遵守政策的概率，但不能保证每次都服从。必须无一例外成立的规则，要在 skill 后面接 deterministic hook。

hooks：构建期的 deterministic guardrails

• 阻止修改生成代码、冻结 package 或受保护路径。

• 文件编辑后自动运行 formatter 和 linter，避免 drift 累积。

• 在 diff 进入 review 前阻止凭据和敏感信息泄漏。

Build 阶段的 hook 应该快、范围小，只检查刚改动的文件；完整测试更适合放在 commit 或 PR。需要人工批准的 hook 则放到 Deploy，避免把人重新放回所有并行 session 的 critical path。

skill 改版时由 policy owner sign off，工程师下一次 session 会自动拿到新版本。skill 还应该有触发测试：用不同说法执行同一任务，确认它每次都会被加载。

parallel sessions 与 subagents

parallel session 是拥有独立 worktree 的完整 Claude Code 实例；subagent 是单个 session 内、带独立 context 和工具权限的 scoped helper。前者提高在途任务数，后者适合反复出现的验证工作。工程师负责拆分任务、控制边界，并 review 所有结果。通常从两到三个 session 开始，只有在 review 跟得上时才继续增加。

verifier.md

---

name: verifier

description: Runs the app and checks the change works before the session

reports done

tools: Bash, Read

---

Start the app with make run. Exercise the changed behavior and the two

nearest neighboring flows. Report what you ran, what you saw, and any

behavior that does not match plan.md. Do not fix anything; report only.

05

TEST

把反馈闭环放进每一次实现

任何任务都应该有自证方式：测试、build、lint 或 screenshot diff。让 session 先发现并修正自己的错误，再把结果交给工程师。

• Bug fix 先写会失败的测试，不允许修改测试来“修绿”。

• UI 工作用浏览器或截图做视觉回归，通常迭代两到三轮。

• 把验证纳入 done 的定义，并用 hook 保护测试文件。

CLAUDE.md

## Verifying your work

- Build: make build (must finish with "Build succeeded")

- Test: make test (all green; never skip or delete a failing test)

- Lint: make lint (zero warnings)

Run all three before reporting any task complete, and paste the output.

在 CI 中持续运行 evals

evals 是 AI-native 时代的 stage-gate QA：每当模型、Prompt、CLAUDE.md、skills 或 hooks 改动，就用真实任务检查 agent 是否仍能交付预期结果。它会随着模型变强而持续更新。

• 从近期工作收集 20 到 50 个真实任务及可接受结果。

• 把每个任务写成 Prompt 加验收条件，结果作为合并门槛。

• 每次生产事故新增一个 eval，长期保留为 regression test。

GitHub Actions

name: Agent evals

on:

pull_request:

paths: ['CLAUDE.md', '.claude/**']

schedule:

- cron: '0 2 * * *'

jobs:

evals:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- run: npm install -g @anthropic-ai/claude-code

反馈闭环和 verifier subagent 不是一回事：闭环贯穿整个任务，随着实现反复运行；verifier 只是把最后一次独立检查封装成一个可复用助手。

把“完成”写成可验证的条件

• 把一串命令封装成 make test、npm test 之类的单一 target，并保证失败时返回 non-zero。

• 在 CLAUDE.md 里写出健康输出，让 Claude 知道什么才算通过。

• 明确量化目标：所有测试通过、截图与 mock 一致、endpoint 返回带新字段的 200。

evals 是 AI-native 版本的 stage-gate QA。每当模型、Prompt、CLAUDE.md、skill 或 hook 改动，CI 都用真实任务检查配置是否仍然有效。每次生产事故都应新增一个 eval，作为长期 regression test。

pass rate 阈值要作为 merge check 执行，运行结果带时间戳并可跨版本比较；修改 agent 配置的团队负责审批结果。

06

DEPLOY

让 AI 进入 PR 与发布审批闭环

Claude 可以 review 别人的 PR，也可以处理自己 PR 收到的评论。常规检查交给 agent，工程师更多判断行为、意图和风险；受监管和高风险代码保留人类审批。

• 用 REVIEW.md 定义 Bugs、Security、Compliance 等 review passes。

• agent 的 finding 不能绕过 code owner 和 branch protection。

• 在评论中 @claude，Claude 处理问题并推送修复，PR thread 保留完整记录。

Hooks 作为审批关卡

Build 阶段的 hook 是无人工参与的 allow 或 block；Deploy 阶段可以使用 ask，让动作暂停等待指定的人批准。不可关闭的 hook 放在 managed settings 中。

JSON

{

"hooks": {

"PreToolUse": [

{

"matcher": "Bash",

"hooks": [{ "type": "command", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/production-gate.sh" }]

}

]

}

}

Bash

#!/bin/bash

cmd=$(jq -r '.tool_input.command' < /dev/stdin)

if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then

if [ -z "$RELEASE_APPROVAL" ]; then exit 2; fi

fi

exit 0

CI/CD 与部署

在 CI/CD 中以非交互方式运行 Claude，先做只读诊断；需要写入时，结果只能通过 PR 和 branch protection 进入主干。把 deploy、status、rollback 暴露为受限的 MCP tools。开发环境更开放，production 由 release manager 授权。

YAML

- name: Triage failed build

if: failure()

run: >

claude -p "Read the build log at out/build.log. Identify the most

likely cause and write a three-line summary for the PR thread." >> triage.md

PR review：让 agent 先处理常规问题

Claude 既可以 review incoming PR，也可以处理自己 PR 收到的评论。技术负责人把 review policy 写进 REVIEW.md，按 Bugs、Security、Compliance 分 pass；工程师保留对行为、意图和风险的最终判断。

REVIEW.md

# Review instructions

## Passes

Run three passes and tag each finding with its pass:

- Bugs: logic errors, broken edge cases, subtle regressions

- Security: injection risks, authentication gaps, PII in logs

- Compliance: the change matches spec.md and plan.md

## What Important means here

Reserve Important for findings that would break behavior, leak data

or breach a policy.

Report at most five nits per review; summarize the rest as a count.

agent 不能批准自己写的代码，separation of duties 仍然保留。finding、修复、评级和批准都记录在 PR history 中，因此 PR 本身就是 audit record。

Managed settings：受监管组织的最后一道边界

团队级 settings 可以随仓库 review，但不可关闭的权限、hooks 和工具 allowlist 应由平台或 IT 管理，放在 managed settings 中。个人工程师不能通过改配置绕过 production gate。

CI/CD：让 agent 走到 gate，但不能穿过 gate

• 先从 read-only 的失败诊断、flaky test 归因和 changelog 草稿开始。

• 需要写入时，只允许通过 PR、branch protection 和 code owner review 进入 main。

• agent job 运行在 sandbox container 中，使用短时、最小权限 token，默认不提供生产凭据。

• 按环境分级 autonomy：development 可自动部署，staging 需要更多检查，production 发布必须由 release manager 授权。

• rollback 必须是一条经常在 staging 演练的路径，并能被 agent 通过受限 MCP tool 调用。

治理原则很简单：agent 可以走到 production gate，但不能自己通过它。

∞

MAINTAIN

让系统自己发现问题，并重新进入 Plan

Maintain 把重点转向 headless 运行。持续监控的 agent 可以从 bug ticket 或线上异常生成 intent.md，经过 requirements、plan、build、test 和 review；阶段之间放一个 deterministic check 或独立 reviewer，决定产出继续流转，还是升级给人处理。

先选一个有稳定 rolling baseline 的指标，例如 CI 测试失败率、发布后的 5xx 比例或 PR cycle time。检测脚本用均值、标准差和 Western Electric 规则识别漂移与尖峰，脚本本身必须 version controlled 且有 unit test。

• 1σ：只记录；2σ：read-only 诊断；3σ：只能提出 PR 或触发预先批准的 runbook。

• 诊断结果按 Stage 1 格式写成 intent.md，再走正常 review gate。

• 修复上线后，为事故补一个 eval，防止问题再次出现。

YAML

metric: ci_test_failure_rate

baseline: rolling_30d

rules: western_electric

tiers:

1sigma: { action: log }

2sigma: { action: diagnose, tools: "Read,Grep,Bash(gh run view *)" }

3sigma: { action: propose, routes: [pull_request, runbook:rollback-deploy] }

— 通过自动化控制带，把生产信号转成可审计的下一项工作。

Claude Tag：让事故响应留在发生现场

Claude Tag：让响应和知识留在同一个 channel

事故也可能从 Slack 或 Teams 的一条消息开始。Claude Tag 以自己的身份加入 channel，先响应、查证指标、提出假设；团队成员可以在同一条 thread 里补充上下文、验证方案和授权动作。通过 MCP，Claude 可以确认指标回到 baseline，并把 post-mortem 写入 version-controlled lessons 文件。

这不只适用于事故。通过 MCP 把 Claude 标记到 ticket 上，小修复走 PR，大问题写成 intent.md，重新回到 Plan。这样请求、诊断、人类授权和修复都留在处理现场，channel 本身就是 audit trail。

事故可能来自深夜 Slack 或 Teams 消息。Claude Tag 以自己的身份加入频道，先响应、查证、提出假设；对话、知识、授权和修复都留在同一个 channel，也就自然留下了 audit trail。小修复走 PR，大问题写成 intent.md，重新回到 Plan。

— channel 同时保存请求、诊断、人类授权和修复结果。

Maintain 的重点是让 Claude 在没有人手动启动 session 的情况下运行。线上监控发现异常后，agent 生成 intent.md，经过需求、计划、实现、测试和 review；阶段之间放一个 deterministic check 或独立 reviewer，决定继续流转还是升级给人。

异常分级与响应

• 1σ：只记录，不调用模型。

• 2σ：以 read-only 权限让 Claude 诊断。

• 3σ：只能开 PR，或触发预先批准的 rollback runbook。

检测脚本负责判断是否越过控制带，模型只负责在权限范围内解释和提出动作。这样触发层保持 deterministic，agent 不会自己改变报警标准。

三个例子

• CI 测试失败率超过 3σ：隔离 flaky test，或打开 revert PR，由 review gate 决定。

• 发布后的 5xx 超过 3σ：触发现有 rollback pipeline。

• PR cycle time 出现 drift：生成报告交给工程负责人，证明这套 harness 不只监控生产指标，也能监控流程指标。

结语

模型和 harness 已经足够成熟，组织要重做的不只是代码生产方式，而是从想法到生产、再到下一次改进的整条 SDLC。

这套转型并不削弱人的作用，反而把人的判断放到真正需要它的地方：需求取舍、风险承诺、受监管发布，以及异常升级。

落地时可以按平台团队的顺序推进：先建立 CLAUDE.md 和 intent home，再加 skills、hooks、持续 evals、PR review 和 production gate，最后让监控和 Claude Tag 把闭环跑起来。