ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

别再用AI生成屎山代码了!Anthropic最新SDLC实战指南

别再用AI生成屎山代码了!Anthropic最新SDLC实战指南 当代码不再是瓶颈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 SDLCAI-native SDLC 不是把人从流程里拿掉而是把原有的控制目标改造成能跟上 agent 速度的执行方式。流程不再是一条直线而是一个由 artifact 驱动的 loop每个阶段提交结果下一阶段读取结果并被自动触发。人类仍然对需要判断的决定负责只是注意力从“盯着 agent 打字”转移到“审什么产物、在哪个 gate 做决定”。传统 SDLC 与 AI-native SDLC下面这张表不是非黑即白的二选一而是两个端点。大多数团队会从其中一两项开始逐步向右侧移动。PlanTRADITIONAL SDLC需求靠委员会、workshop 和签字确认再手写成文档。AI-NATIVE SDLCClaude 从原始信息中提炼痛点写入人能读、agent 能执行的 intent.md。DesignTRADITIONAL SDLC分析师写 spec设计师再拆解。AI-NATIVE SDLC一次会话完成需求与设计标准由 skills 固化并进入 git。BuildTRADITIONAL SDLC代码和测试手写文档通常事后补。AI-NATIVE SDLCAI 生成代码与测试组织知识沉淀在 CLAUDE.md 和 skills 中。TestTRADITIONAL SDLCQA 在阶段边界设置闸门。AI-NATIVE SDLCContinuous evals 贯穿实现过程。DeployTRADITIONAL SDLC人工逐行 review治理依赖周期性会议。AI-NATIVE SDLCagent 先处理常规 review人类聚焦高风险判断hooks 负责审批关卡。MaintainTRADITIONAL SDLC人盯着线上报警和 bug。AI-NATIVE SDLCagent 监控生产异常控制带会生成新的 intent.md重新进入闭环。贯穿右侧的主线是每个阶段都会提交一个 artifactintent.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 和触发条件连接起来的闭环。02PLAN把想法变成 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-serviceAuthor: J. Ortiz (claims operations). Status: draft.## ProblemCustomers phone the contact center to ask where their claim is.Handlers spend roughly a third of call time on status-only queries.## Proposed outcomeCustomers see claim status, next step and expected date in the portal.## ConstraintsNo new PII in the portal session. Existing authentication only.治理依据就是已提交的 intent.md作者、时间和修订历史都在 git 中产品负责人作出接受或拒绝的判断。03DESIGN让需求与设计在一次会话里收敛intent.md 被接受后Claude 根据组织的 brand、security、compliance 和 UX skills 生成 requirements and design spec。产品负责人审阅结果但不再亲自把需求重写一遍。产品负责人可以在 Claude Designbeta里从 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。PromptRead 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.04BUILD从 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 changeportal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py,claims-api/tests/test_status.py## Order of work1. Add the status endpoint behind existing auth.2. Panel against the endpoint.3. Wire into the portal nav.## RisksThe claims-core API rate-limits at 50 rps; the panel must cache.CLAUDE.md、skills 与 hooksCLAUDE.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 使用独立 worktreesubagent 负责单一重复任务。工程师的职责从盯每一次编辑转向拆任务、定边界、审结果。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-reviewdescription: Apply the API security standard. Use whenever creating ormodifying an external-facing endpoint, reviewing API code, orgenerating an OpenAPI spec.---# Secure API reviewWhen 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 与 subagentsparallel session 是拥有独立 worktree 的完整 Claude Code 实例subagent 是单个 session 内、带独立 context 和工具权限的 scoped helper。前者提高在途任务数后者适合反复出现的验证工作。工程师负责拆分任务、控制边界并 review 所有结果。通常从两到三个 session 开始只有在 review 跟得上时才继续增加。verifier.md---name: verifierdescription: Runs the app and checks the change works before the sessionreports donetools: Bash, Read---Start the app with make run. Exercise the changed behavior and the twonearest neighboring flows. Report what you ran, what you saw, and anybehavior that does not match plan.md. Do not fix anything; report only.05TEST把反馈闭环放进每一次实现任何任务都应该有自证方式测试、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 中持续运行 evalsevals 是 AI-native 时代的 stage-gate QA每当模型、Prompt、CLAUDE.md、skills 或 hooks 改动就用真实任务检查 agent 是否仍能交付预期结果。它会随着模型变强而持续更新。• 从近期工作收集 20 到 50 个真实任务及可接受结果。• 把每个任务写成 Prompt 加验收条件结果作为合并门槛。• 每次生产事故新增一个 eval长期保留为 regression test。GitHub Actionsname: Agent evalson:pull_request:paths: [CLAUDE.md, .claude/**]schedule:- cron: 0 2 * * *jobs:evals:runs-on: ubuntu-lateststeps:- uses: actions/checkoutv4- 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 配置的团队负责审批结果。06DEPLOY让 AI 进入 PR 与发布审批闭环Claude 可以 review 别人的 PR也可以处理自己 PR 收到的评论。常规检查交给 agent工程师更多判断行为、意图和风险受监管和高风险代码保留人类审批。• 用 REVIEW.md 定义 Bugs、Security、Compliance 等 review passes。• agent 的 finding 不能绕过 code owner 和 branch protection。• 在评论中 claudeClaude 处理问题并推送修复PR thread 保留完整记录。Hooks 作为审批关卡Build 阶段的 hook 是无人工参与的 allow 或 blockDeploy 阶段可以使用 ask让动作暂停等待指定的人批准。不可关闭的 hook 放在 managed settings 中。JSON{hooks: {PreToolUse: [{matcher: Bash,hooks: [{ type: command, command: ${CLAUDE_PROJECT_DIR}/.claude/hooks/production-gate.sh }]}]}}Bash#!/bin/bashcmd$(jq -r .tool_input.command /dev/stdin)if [[ $cmd *deploy* $cmd *production* ]]; thenif [ -z $RELEASE_APPROVAL ]; then exit 2; fifiexit 0CI/CD 与部署在 CI/CD 中以非交互方式运行 Claude先做只读诊断需要写入时结果只能通过 PR 和 branch protection 进入主干。把 deploy、status、rollback 暴露为受限的 MCP tools。开发环境更开放production 由 release manager 授权。YAML- name: Triage failed buildif: failure()run: claude -p Read the build log at out/build.log. Identify the mostlikely cause and write a three-line summary for the PR thread. triage.mdPR review让 agent 先处理常规问题Claude 既可以 review incoming PR也可以处理自己 PR 收到的评论。技术负责人把 review policy 写进 REVIEW.md按 Bugs、Security、Compliance 分 pass工程师保留对行为、意图和风险的最终判断。REVIEW.md# Review instructions## PassesRun 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 hereReserve Important for findings that would break behavior, leak dataor 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默认不提供生产凭据。• 按环境分级 autonomydevelopment 可自动部署staging 需要更多检查production 发布必须由 release manager 授权。• rollback 必须是一条经常在 staging 演练的路径并能被 agent 通过受限 MCP tool 调用。治理原则很简单agent 可以走到 production gate但不能自己通过它。∞MAINTAIN让系统自己发现问题并重新进入 PlanMaintain 把重点转向 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防止问题再次出现。YAMLmetric: ci_test_failure_ratebaseline: rolling_30drules: western_electrictiers: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 里补充上下文、验证方案和授权动作。通过 MCPClaude 可以确认指标回到 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。检测脚本负责判断是否越过控制带模型只负责在权限范围内解释和提出动作。这样触发层保持 deterministicagent 不会自己改变报警标准。三个例子• 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 把闭环跑起来。
返回列表