先别问 AI 写了多少代码
更有用的问题是：团队敢不敢使用、敢不敢上线这次改动？功能能编译，不代表权限正确；桌面截图好看，不代表手机能操作；测试全绿，也不代表已经有人批准发布。
Anthropic 在 2026 年 8 月 21 日发布的手册，把 AI 放进需求、设计、实现、测试、部署、维护六个环节来看：用可审查的记录连接工作，把重要决定的责任留给人。SDLC 就是软件从想法走到上线、再持续维护的全过程。
这篇是 Onevium 的独立实践解读，不是官方译文，也不是全文转载。下面的案例、检查表和四张图解均为原创教学材料，不含真实客户数据，不是效率实测报告，也不代表 Anthropic 为 Onevium 背书。
- 语法与类型检查
- 构建产物可生成
- 已有单元测试
- 普通成员会被正确拒绝吗？
- 过期邀请能恢复流程吗？
- 手机上能完成操作吗？
从一条真的会出现在工作群里的任务开始
假设一个小型企业软件团队正在做“邀请成员”功能。产品经理在飞书或钉钉里说：“周五上线前，帮我检查一下邀请流程。”听起来很清楚，可研发马上会遇到几个问题：谁有权邀请？链接过期怎么办？测试时能不能真的发邮件？
好的任务既说明要做到什么，也说明不能做什么。本例允许助手用虚构账号检查代码与预发布环境；不允许给客户发邮件、修改计费或部署生产。下面的方括号需要换成你们自己的信息，不能原样当成可执行配置。
目标：验证成员邀请流程。
环境：[预发布地址]，只使用虚构测试账号。
预期：管理员可以邀请，普通成员不能邀请。
链接过期后，应提供重新申请邀请的入口。
检查桌面、手机和键盘操作。
交付：问题清单、复现步骤、截图与测试结果。
不要给真实客户发邮件，不要部署生产。
缺少权限或测试数据时，停止并说明需要什么。先把行为说清楚，再把页面做漂亮
产品经理决定哪些角色可以邀请；设计师补齐加载、成功、拒绝和过期状态；研发确认服务端与页面执行同一套规则。助手可以起草、核对这些材料，但不能替公司决定访问权限。
例如，把普通成员看到的“邀请”按钮藏起来，不等于完成权限校验。绕过页面、直接请求接口时，普通成员也必须被拒绝，而且不能创建邀请。这比一句“界面看起来没问题”更能说明验收要求。
把决定留在团队已有的需求单或规格文档里，再从任务中关联过去。不要为了显得“AI 原生”，额外制造一份互相冲突的权限规则。
- 01需求产品经理邀请谁，解决什么问题
- 02设计设计＋研发角色矩阵与页面状态
- 03实现研发小范围代码变更
- 04验证测试＋研发测试记录与页面证据
- 05上线发布负责人明确授权与回退方案
- 06观察运维＋产品邀请成功率与用户反馈
给 Claude Code 背景、计划，也给它真正的限制
CLAUDE.md 适合写项目背景，例如测试命令、权限逻辑在哪。Skill 适合封装可重复的做事步骤，例如检查邀请接口。计划模式则让 Claude Code 先读项目、提出方案，再进入修改。这三件事用途不同，不必全塞进一个超长提示词。
文字指令不是权限系统。PreToolUse Hook 可以在匹配的工具调用前介入，但一个自己写的命令过滤脚本，不等于完整的生产安全边界。部署凭据、仓库保护和环境审批仍要在对应系统中落实。使用前要核对当前文档与你们自己的配置。
- 背景要具体：指出实际子项目与测试命令，不要默认所有仓库都用同一套脚本。
- 计划要能审：说清会修改哪些权限判断和页面状态，分别如何验证。
- 范围要收住：邀请功能的修改，不要顺手扩大成依赖升级或整套账号系统重写。
要能揭穿错误实现的证据，不要只看成功截图
一张邀请成功的截图，说明不了多少问题。要分别用管理员、普通成员、过期链接和已使用链接去测；既看返回结果，也看系统里究竟产生了什么状态，不能只看页面上的绿色提示。
修复回归问题时，先在旧行为上证明问题确实存在，再用同一个用例检查修复结果。如果需求真的变了，测试断言可以调整，但要单独解释；删掉失败断言，不算修好了。
界面还要在明确的屏幕尺寸下检查，并走一遍键盘操作：错误提示能不能看见，焦点会不会丢，小屏是否藏住了恢复入口。这些问题，构建成功回答不了。
- 越权请求：普通成员从页面或直接调用接口，都不能创建邀请。
- 过期链接：解释原因，提供约定的恢复入口，但不能继续接受旧令牌。
- 重复请求：重试不能悄悄生成多份邀请或意外发送多封邮件。
- 证据记录：写清测试版本、环境、用例、预期、实际结果，以及还没验证的部分。
把“能不能上线”变成一个容易判断的问题
“做完了”混在一起说了太多事。代码可能写好了但没测，测过了但没批准，批准了但没部署，部署了却还没观察。把这些状态分开，团队才知道下一步该找谁。
本例的发布说明应该指出候选版本，关联权限测试与浏览器证据，列出未解决问题，并说明出现异常时怎样关闭功能。如果数据库变更无法安全逆转，就不能把“回退应用版本”说成“数据也能跟着恢复”。
发布负责人决定是否继续。测试通过、助手审查通过，都不能补上缺失的授权。上线后还要观察真实的邀请创建与接受情况，而不只是打开首页确认返回正常。
实现状态：[候选版本与变更链接]
验证结果：[权限用例]＋[桌面／手机证据]
已知缺口：[未验证项，或在明确范围内无遗留项]
发布审批：等待发布负责人
生产部署：尚未执行
恢复方式：[功能开关或已演练的恢复流程]
上线后观察：[负责观察的岗位]把结果带回发起任务的那段对话
产品经理不应该靠翻终端日志拼出进度。好的群消息回执，会说明检查了什么、失败了什么、证据在哪、下一步由谁决定。关联权威需求单或变更记录即可，不要把密钥或完整内部对话贴到群里。
下面故意使用一个很日常的例子：助手发现缺少恢复入口，研发限定修复范围，最后明确等待发布审批。中间没有“自动把所有东西都上线”的魔法步骤。
- 产品经理请验证邀请流程：非管理员不能邀请；过期链接能重新申请。仅测预发布，先不要上线。
- 任务助手已完成桌面与手机端检查。权限拒绝符合预期；发现过期页面没有重新申请入口。已附复现步骤与截图。
- 研发补齐入口后重新回归，并附上变更链接。上线仍由发布负责人确认。
- 任务助手修复与回归记录已补充。当前状态：待发布审批；尚未部署生产。
Onevium 放在哪一环，哪些还得靠你们的基础设施
Onevium 提供承载任务、浏览器与终端操作、计划任务及团队渠道的桌面工作空间。配置好相关工具和权限后，邀请流程的排查可以从渠道任务开始，在预览环境中执行，再把结果反馈给团队。
但工作空间不能替代受保护的分支、CI 规则、按环境隔离的凭据和公司的发布审批。这些限制仍需落实在真正执行和授权的系统里。发报告前确认渠道权限与接收范围，对外演示只使用虚构数据。
先小到能看清问题，再扩大自动化
对这个团队来说，第一个试点可以只是只读分析邀请失败原因；第二步才是在独立分支里修复，并给出能复现的测试。团队能稳定审查这些结果之后，再接定时触发或扩大写入权限。
不要因为工具支持并行，就同时开五个改动。如果最后仍由同一个人理解并批准所有结果，这个人的审查能力就是实实在在的上限。范围小一点，反而容易看出缺陷、费用和权限缺口。
- 01先看得见只读分析一个邀请失败问题。下一步条件：能从原始记录复现结论。
- 02再改得准在独立分支修复并回归。下一步条件：权限与过期场景都可验证。
- 03最后才扩大接入定时检查与发布审批。下一步条件：凭据隔离，回退经过演练。
看交付有没有变好，不看代码改了多少行
试点之前，记录同类邀请功能改动通常花多久、时间等在哪里；试点之后，拿复杂度相近的工作来比较，不要把改文案和重写鉴权放在一起。助手使用费用，以及人花在检查、纠错上的时间，也要算进去。
样本少时，每个百分比旁边都保留实际案例数。两个任务成功，并不能证明一个稳定的成功率。遇到失败应该分析原因，而不是把难题从统计分母里删掉。
- 流转效率：从需求确认到验证上线的总耗时，并单独标出等待时间。
- 交付质量：漏到线上的邀请缺陷、重复故障，以及审查后的返工。
- 人的投入：检查和纠错花了多久，而不只是少打了多少代码。
- 边界执行：有没有缺审批、发错接收人，或在约定环境之外操作。
最后记住这一件事
选一个功能，把预期说具体，把限制落实，再交回别人能够检查的证据。如果团队能反复做到这些，同时说得清风险和责任在哪里，就有了值得扩大的工作方式。
不必先给所有会议改名字，也不必先换掉所有工具。你需要的是：开始时任务让人听得懂，结束时结果让人信得过。