[{"data":1,"prerenderedAt":908},["ShallowReactive",2],{"blog-codex-team-adoption":3},{"id":4,"title":5,"body":6,"category":894,"date":895,"description":16,"extension":896,"meta":897,"navigation":310,"path":898,"seo":899,"stem":900,"tags":901,"__hash__":907},"blog\u002Fblog\u002Fcodex-team-adoption.md","Codex 团队落地实践：从项目 Onboarding 到 Spec-driven 工作流",{"type":7,"value":8,"toc":877},"minimark",[9,13,17,20,32,37,43,120,123,141,148,152,155,158,168,171,177,180,185,189,195,198,204,207,239,242,257,262,266,269,272,324,327,330,336,341,345,348,393,396,426,440,445,449,452,455,468,485,488,494,500,590,596,655,658,663,667,670,675,681,685,691,695,701,705,711,715,721,726,730,733,818,824,829,832,835,838,860,863,866,873],[10,11,5],"h1",{"id":12},"codex-团队落地实践从项目-onboarding-到-spec-driven-工作流",[14,15,16],"p",{},"个人用 Codex，追求的是效率。团队用 Codex，追求的是一致性。",[14,18,19],{},"如果一个团队里每个人都用自己的 prompt、自己的权限配置、自己的隐性规范，Codex 很快会变成“每个人手里不同脾气的外包同事”。有的人让它先写测试，有的人让它直接改；有的人限制只读，有的人默认 full access；有的人把内部框架文档贴进 prompt，有的人让它靠猜。",[14,21,22,23,27,28,31],{},"团队落地的关键，不是让每个人更会 prompt，而是把团队的工程判断沉淀成可复用的系统：",[24,25,26],"code",{},"AGENTS.md"," 写铁律，",[24,29,30],{},".codex\u002Fconfig.toml"," 写安全边界，Skills 写流程，OpenSpec 写需求语义，Hooks 和 review 做验收。",[33,34,36],"h2",{"id":35},"_1-四类信息分开承载","1. 四类信息分开承载",[14,38,39,40,42],{},"团队规范通常有四类，不要全塞进一份 ",[24,41,26],{},"：",[44,45,46,62],"table",{},[47,48,49],"thead",{},[50,51,52,56,59],"tr",{},[53,54,55],"th",{},"信息类型",[53,57,58],{},"承载物",[53,60,61],{},"例子",[63,64,65,78,91,102],"tbody",{},[50,66,67,71,75],{},[68,69,70],"td",{},"铁律",[68,72,73],{},[24,74,26],{},[68,76,77],{},"必须 pnpm、禁止 PII 日志、金额必须 Money",[50,79,80,83,88],{},[68,81,82],{},"安全\u002F执行策略",[68,84,85,87],{},[24,86,30],{}," \u002F 管理配置",[68,89,90],{},"sandbox、approval、MCP、hooks",[50,92,93,96,99],{},[68,94,95],{},"SOP",[68,97,98],{},"Skills",[68,100,101],{},"新建模块、TDD、内部 RPC、review 流程",[50,103,104,107,117],{},[68,105,106],{},"参考资料",[68,108,109,112,113,116],{},[24,110,111],{},"docs\u002F"," \u002F Skill ",[24,114,115],{},"references\u002F"," \u002F MCP",[68,118,119],{},"框架文档、领域手册、历史 RFC",[14,121,122],{},"一个简单判断：",[124,125,126,132,135,138],"ul",{},[127,128,129,130],"li",{},"“Codex 每次都必须知道” → ",[24,131,26],{},[127,133,134],{},"“Codex 遇到某类任务时才需要按步骤做” → Skill",[127,136,137],{},"“这是工具能力或权限边界” → config",[127,139,140],{},"“这是长文档或外部事实” → docs \u002F MCP",[14,142,143,147],{},[144,145,146],"strong",{},"小结："," 团队落地第一步是分类。放错地方，后面所有 prompt 都会变胖。",[33,149,151],{"id":150},"_2-新项目-day-1先定骨架再写业务","2. 新项目 Day 1：先定骨架，再写业务",[14,153,154],{},"新项目最容易犯的错，是第一天就让 Codex 实现业务。目录结构、测试策略、边界分层一旦歪了，后面会一路带偏。",[14,156,157],{},"更稳的 Day 1 流程是：",[159,160,166],"pre",{"className":161,"code":163,"language":164,"meta":165},[162],"language-text","1. 明确鉴权、计费、安全边界\n2. 让 Codex 只读当前目录，规划 skeleton\n3. review 目录结构、测试框架、lint\u002Ftypecheck 命令\n4. 写根 AGENTS.md\n5. 写项目级 .codex\u002Fconfig.toml\n6. 加最小 hooks：危险命令、基础检查\n7. 建第一批 Skills：TDD、新模块、commit style\n8. 用一个小任务校准输出风格\n","text","",[24,167,163],{"__ignoreMap":165},[14,169,170],{},"Prompt 可以这样写：",[159,172,175],{"className":173,"code":174,"language":164,"meta":165},[162],"我要用 TypeScript 搭一个支付后台服务。\n团队规范是 DDD \u002F TDD \u002F Clean Architecture。\n先不要实现具体业务。\n请阅读当前目录，给出最小可运行 skeleton 的计划：\n1. 文件结构\n2. 测试框架\n3. lint\u002Ftypecheck 命令\n4. 第一批验收测试\n5. 风险和非目标\n",[24,176,174],{"__ignoreMap":165},[14,178,179],{},"你 review 计划后再让 Codex 执行。不要跳过这一步。Codex 写代码很快，写错方向也很快。",[14,181,182,184],{},[144,183,146],{}," 新项目先固化工程骨架，再写业务。目录和测试策略是最早也最贵的决策。",[33,186,188],{"id":187},"_3-存量大仓先考古再落规则","3. 存量大仓：先考古，再落规则",[14,190,191,192,194],{},"老仓库更复杂。它可能有内部闭源框架、历史遗留模块、风格断层、没人敢碰的上帝文件。此时 Codex onboarding 的第一步不是写 ",[24,193,26],{},"，而是考古。",[14,196,197],{},"用只读模式启动，让 Codex 先生成项目考古报告：",[159,199,202],{"className":200,"code":201,"language":164,"meta":165},[162],"先不要改代码。请作为新入职资深工程师，生成项目考古报告：\n\n1. 识别语言、构建系统、包管理器、测试框架\n2. 识别顶层目录职责\n3. 识别内部包及典型用法\n4. 找出历史沉淀：deprecated、TODO、风格断层\n5. 识别测试策略分布\n6. 识别危险区域：热点文件、循环依赖、无测试核心模块\n\n不要猜。不确定处写 UNKNOWN。\n如果需要读超过 20 个文件，先派只读 subagent 分目录探索。\n",[24,203,201],{"__ignoreMap":165},[14,205,206],{},"根据报告再写规则：",[124,208,209,215,221,227,233],{},[127,210,211,212,214],{},"根 ",[24,213,26],{},"：项目速览、铁律、目录地图、命令",[127,216,217,218,220],{},"子目录 ",[24,219,26],{},"：模块特有规范",[127,222,223,226],{},[24,224,225],{},"AGENTS.override.md","：高风险目录的覆盖规则",[127,228,229,232],{},[24,230,231],{},".agents\u002Fskills\u002F","：内部框架和方法论",[127,234,235,238],{},[24,236,237],{},"docs\u002Fframeworks\u002F","：长文档索引",[14,240,241],{},"内部框架尤其不能让 Codex 猜。三种做法按 ROI 排序：",[243,244,245,248,254],"ol",{},[127,246,247],{},"写 Skill，带 references",[127,249,250,251,253],{},"同步真实 docs，让根 ",[24,252,26],{}," 只放索引",[127,255,256],{},"让 Codex 从真实代码归纳 Skill 草稿，再人工 review",[14,258,259,261],{},[144,260,146],{}," 存量项目要先“读懂历史”，再“写下规则”。没有考古就写指导，很容易把错误理解制度化。",[33,263,265],{"id":264},"_4-用风格锚点代替抽象说教","4. 用风格锚点代替抽象说教",[14,267,268],{},"团队规范里最难写清楚的，是风格。命名、分层、错误处理、日志粒度、测试组织方式，这些东西写成 100 条自然语言规则也不一定准。",[14,270,271],{},"更好的方式是引用标准答案文件：",[159,273,277],{"className":274,"code":275,"language":276,"meta":165,"style":165},"language-markdown shiki shiki-themes github-dark","## 风格锚点\n实现新模块时，优先模仿：\n- src\u002Fmodules\u002Forder\u002F：命名、分层、错误处理\n- src\u002Fmodules\u002Finventory\u002F：测试组织方式\n\n不要模仿：\n- src\u002Fmodules\u002Flegacy-pricing\u002F：历史遗留，即将废弃\n","markdown",[24,278,279,287,293,299,305,312,318],{"__ignoreMap":165},[280,281,284],"span",{"class":282,"line":283},"line",1,[280,285,286],{},"## 风格锚点\n",[280,288,290],{"class":282,"line":289},2,[280,291,292],{},"实现新模块时，优先模仿：\n",[280,294,296],{"class":282,"line":295},3,[280,297,298],{},"- src\u002Fmodules\u002Forder\u002F：命名、分层、错误处理\n",[280,300,302],{"class":282,"line":301},4,[280,303,304],{},"- src\u002Fmodules\u002Finventory\u002F：测试组织方式\n",[280,306,308],{"class":282,"line":307},5,[280,309,311],{"emptyLinePlaceholder":310},true,"\n",[280,313,315],{"class":282,"line":314},6,[280,316,317],{},"不要模仿：\n",[280,319,321],{"class":282,"line":320},7,[280,322,323],{},"- src\u002Fmodules\u002Flegacy-pricing\u002F：历史遗留，即将废弃\n",[14,325,326],{},"Codex 模仿已有代码的能力，通常强于按抽象规则凭空生成风格。好样本比长篇规范更接近“可执行的团队品味”。",[14,328,329],{},"风格锚点也适合写进 prompt：",[159,331,334],{"className":332,"code":333,"language":164,"meta":165},[162],"参考 src\u002Fmodules\u002Forder\u002F 的结构、命名、错误处理、日志粒度，\n为 PaymentService 添加同风格的退款用例。\n",[24,335,333],{"__ignoreMap":165},[14,337,338,340],{},[144,339,146],{}," 抽象规则告诉 Codex “应该像什么”，风格锚点直接给它“标准答案”。后者通常更有效。",[33,342,344],{"id":343},"_5-把-tdd-ddd-写成硬约束","5. 把 TDD \u002F DDD 写成硬约束",[14,346,347],{},"如果团队真的重视 TDD，就不要写“建议先写测试”。Agent 对软建议的执行力很弱，要写成硬约束：",[159,349,351],{"className":274,"code":350,"language":276,"meta":165,"style":165},"## TDD 强制流程\n写任何业务代码前必须：\n1. 先写覆盖验收条件的失败测试\n2. 运行测试确认失败\n3. 写最小实现让测试通过\n4. 重构并保持测试绿\n\n跳过 1-2 直接写实现视为严重违规，必须重做。\n",[24,352,353,358,363,368,373,378,383,387],{"__ignoreMap":165},[280,354,355],{"class":282,"line":283},[280,356,357],{},"## TDD 强制流程\n",[280,359,360],{"class":282,"line":289},[280,361,362],{},"写任何业务代码前必须：\n",[280,364,365],{"class":282,"line":295},[280,366,367],{},"1. 先写覆盖验收条件的失败测试\n",[280,369,370],{"class":282,"line":301},[280,371,372],{},"2. 运行测试确认失败\n",[280,374,375],{"class":282,"line":307},[280,376,377],{},"3. 写最小实现让测试通过\n",[280,379,380],{"class":282,"line":314},[280,381,382],{},"4. 重构并保持测试绿\n",[280,384,385],{"class":282,"line":320},[280,386,311],{"emptyLinePlaceholder":310},[280,388,390],{"class":282,"line":389},8,[280,391,392],{},"跳过 1-2 直接写实现视为严重违规，必须重做。\n",[14,394,395],{},"DDD 也一样：",[159,397,399],{"className":274,"code":398,"language":276,"meta":165,"style":165},"## DDD 约束\n- 领域层不得 import infrastructure \u002F interfaces\n- Entity 只能通过 Repository 持久化\n- 业务不变量必须通过 Entity \u002F ValueObject 表达\n- 每个聚合根必须有 invariant 测试\n",[24,400,401,406,411,416,421],{"__ignoreMap":165},[280,402,403],{"class":282,"line":283},[280,404,405],{},"## DDD 约束\n",[280,407,408],{"class":282,"line":289},[280,409,410],{},"- 领域层不得 import infrastructure \u002F interfaces\n",[280,412,413],{"class":282,"line":295},[280,414,415],{},"- Entity 只能通过 Repository 持久化\n",[280,417,418],{"class":282,"line":301},[280,419,420],{},"- 业务不变量必须通过 Entity \u002F ValueObject 表达\n",[280,422,423],{"class":282,"line":307},[280,424,425],{},"- 每个聚合根必须有 invariant 测试\n",[14,427,428,429,432,433,432,436,439],{},"更进一步，把这些流程做成 Skill，比如 ",[24,430,431],{},"add-test-tdd","、",[24,434,435],{},"new-module-ddd",[24,437,438],{},"billing-change","。这样 Codex 遇到对应任务时，不只是“知道规则”，而是按步骤执行：先读哪些文件、先写哪些测试、跑哪些命令、输出什么验收结果。",[14,441,442,444],{},[144,443,146],{}," 团队方法论要变成硬约束和可执行流程。不要指望一句“请注意 TDD”能稳定改变行为。",[33,446,448],{"id":447},"_6-spec-driven让-codex-知道做什么","6. Spec-driven：让 Codex 知道“做什么”",[14,450,451],{},"很多 Codex 翻车不是实现能力问题，而是需求语义太薄。",[14,453,454],{},"“支持退款”这四个字缺太多信息：几天内能退？部分退款吗？履约后能退吗？重复请求怎么办？支付网关乱序回调怎么办？订单状态怎么变？错误码是什么？",[14,456,457,458,432,461,432,464,467],{},"Spec-driven 的价值，是把这些语义写成可 review 的资产。目录名不重要，可以叫 OpenSpec，也可以叫 ",[24,459,460],{},"specs\u002F",[24,462,463],{},"docs\u002Fspecs\u002F",[24,465,466],{},".changes\u002F","。关键是每次行为变化都有：",[124,469,470,473,476,479,482],{},[127,471,472],{},"为什么改",[127,474,475],{},"改什么",[127,477,478],{},"不改什么",[127,480,481],{},"怎么验收",[127,483,484],{},"哪些能力被改变",[14,486,487],{},"一个 change 可以长这样：",[159,489,492],{"className":490,"code":491,"language":164,"meta":165},[162],"openspec\u002F\n└── changes\u002F\n    └── add-refund-window\u002F\n        ├── proposal.md\n        ├── tasks.md\n        └── specs\u002F\n            └── billing\u002F\n                └── spec.md\n",[24,493,491],{"__ignoreMap":165},[14,495,496,499],{},[24,497,498],{},"proposal.md"," 写意图和边界：",[159,501,503],{"className":274,"code":502,"language":276,"meta":165,"style":165},"# add-refund-window\n\n## Why\n用户支付后发现下错单，需要在订单未履约前自助退款。\n当前只能人工客服处理，响应慢且运营成本高。\n\n## What Changes\n- 新增 7 天自助退款窗口\n- 只允许 PAID 且未履约订单退款\n- 退款请求必须幂等\n- 退款成功后订单进入 REFUNDED\n\n## Non-Goals\n- 不支持部分退款\n- 不改支付网关 SDK\n- 不重构历史对账任务\n",[24,504,505,510,514,519,524,529,533,538,543,549,555,561,566,572,578,584],{"__ignoreMap":165},[280,506,507],{"class":282,"line":283},[280,508,509],{},"# add-refund-window\n",[280,511,512],{"class":282,"line":289},[280,513,311],{"emptyLinePlaceholder":310},[280,515,516],{"class":282,"line":295},[280,517,518],{},"## Why\n",[280,520,521],{"class":282,"line":301},[280,522,523],{},"用户支付后发现下错单，需要在订单未履约前自助退款。\n",[280,525,526],{"class":282,"line":307},[280,527,528],{},"当前只能人工客服处理，响应慢且运营成本高。\n",[280,530,531],{"class":282,"line":314},[280,532,311],{"emptyLinePlaceholder":310},[280,534,535],{"class":282,"line":320},[280,536,537],{},"## What Changes\n",[280,539,540],{"class":282,"line":389},[280,541,542],{},"- 新增 7 天自助退款窗口\n",[280,544,546],{"class":282,"line":545},9,[280,547,548],{},"- 只允许 PAID 且未履约订单退款\n",[280,550,552],{"class":282,"line":551},10,[280,553,554],{},"- 退款请求必须幂等\n",[280,556,558],{"class":282,"line":557},11,[280,559,560],{},"- 退款成功后订单进入 REFUNDED\n",[280,562,564],{"class":282,"line":563},12,[280,565,311],{"emptyLinePlaceholder":310},[280,567,569],{"class":282,"line":568},13,[280,570,571],{},"## Non-Goals\n",[280,573,575],{"class":282,"line":574},14,[280,576,577],{},"- 不支持部分退款\n",[280,579,581],{"class":282,"line":580},15,[280,582,583],{},"- 不改支付网关 SDK\n",[280,585,587],{"class":282,"line":586},16,[280,588,589],{},"- 不重构历史对账任务\n",[14,591,592,595],{},[24,593,594],{},"spec.md"," 写行为，不写实现：",[159,597,599],{"className":274,"code":598,"language":276,"meta":165,"style":165},"### Requirement: Self-service refund window\n系统 MUST allow a customer to request a full refund when:\n- the order status is PAID\n- fulfillment has not started\n- the payment time is within 7 calendar days\n\n#### Scenario: duplicate refund request is idempotent\n- GIVEN a refund request with idempotency key abc\n- WHEN the same request is submitted twice\n- THEN only one gateway refund is created\n- AND both responses return the same refund id\n",[24,600,601,606,611,616,621,626,630,635,640,645,650],{"__ignoreMap":165},[280,602,603],{"class":282,"line":283},[280,604,605],{},"### Requirement: Self-service refund window\n",[280,607,608],{"class":282,"line":289},[280,609,610],{},"系统 MUST allow a customer to request a full refund when:\n",[280,612,613],{"class":282,"line":295},[280,614,615],{},"- the order status is PAID\n",[280,617,618],{"class":282,"line":301},[280,619,620],{},"- fulfillment has not started\n",[280,622,623],{"class":282,"line":307},[280,624,625],{},"- the payment time is within 7 calendar days\n",[280,627,628],{"class":282,"line":314},[280,629,311],{"emptyLinePlaceholder":310},[280,631,632],{"class":282,"line":320},[280,633,634],{},"#### Scenario: duplicate refund request is idempotent\n",[280,636,637],{"class":282,"line":389},[280,638,639],{},"- GIVEN a refund request with idempotency key abc\n",[280,641,642],{"class":282,"line":545},[280,643,644],{},"- WHEN the same request is submitted twice\n",[280,646,647],{"class":282,"line":551},[280,648,649],{},"- THEN only one gateway refund is created\n",[280,651,652],{"class":282,"line":557},[280,653,654],{},"- AND both responses return the same refund id\n",[14,656,657],{},"这类 scenario 对 Codex 非常友好，因为它可以自然映射到测试。",[14,659,660,662],{},[144,661,146],{}," Spec-driven 不是形式主义。它把“需求语义”变成 Codex 可以读取、测试可以覆盖、review 可以对照的东西。",[33,664,666],{"id":665},"_7-codex-spec-的执行流程","7. Codex × Spec 的执行流程",[14,668,669],{},"有了 spec，不要直接说“照着实现”。更稳的是五步：",[671,672,674],"h3",{"id":673},"step-1只读理解","Step 1：只读理解",[159,676,679],{"className":677,"code":678,"language":164,"meta":165},[162],"先不要改代码。请阅读：\n- AGENTS.md\n- openspec\u002Fproject.md\n- changes\u002Fadd-refund-window\u002Fproposal.md\n- tasks.md\n- specs\u002Fbilling\u002Fspec.md\n\n输出：\n1. 需求摘要\n2. 需要澄清的问题\n3. 可能涉及代码位置\n4. 测试计划\n5. 风险和非目标\n不确定处写 UNKNOWN。\n",[24,680,678],{"__ignoreMap":165},[671,682,684],{"id":683},"step-2spec-到测试映射","Step 2：spec 到测试映射",[159,686,689],{"className":687,"code":688,"language":164,"meta":165},[162],"请把每个 Scenario 映射到具体测试：\n- 测试文件路径\n- 测试名\n- Given\u002FWhen\u002FThen 如何落到代码\n- 需要 mock 或 fake 的边界\n- 哪些测试必须先失败\n只输出计划，不改文件。\n",[24,690,688],{"__ignoreMap":165},[671,692,694],{"id":693},"step-3tdd-执行","Step 3：TDD 执行",[159,696,699],{"className":697,"code":698,"language":164,"meta":165},[162],"按 tasks.md 一次只做一项：\n1. 先写失败测试\n2. 运行该测试，确认失败原因是行为缺失\n3. 写最小实现\n4. 运行相关测试\n5. 更新 tasks.md 勾选完成项\n",[24,700,698],{"__ignoreMap":165},[671,702,704],{"id":703},"step-4完成前验收","Step 4：完成前验收",[159,706,709],{"className":707,"code":708,"language":164,"meta":165},[162],"逐条对照 spec：\n1. What Changes 是否全部实现\n2. 每个 Scenario 是否有测试覆盖\n3. tasks.md 是否全部完成\n4. Non-Goals 是否被越界修改\n5. 运行相关测试和 typecheck\n6. 输出残余风险\n",[24,710,708],{"__ignoreMap":165},[671,712,714],{"id":713},"step-5review-查偏差","Step 5：review 查偏差",[159,716,719],{"className":717,"code":718,"language":164,"meta":165},[162],"Review 当前 diff，重点找：\n1. 实现是否偏离 spec\n2. 是否偷偷实现 Non-Goals\n3. 是否缺少 Scenario 覆盖\n4. 幂等、并发、安全、数据一致性风险\n",[24,720,718],{"__ignoreMap":165},[14,722,723,725],{},[144,724,146],{}," Spec 定义目标，TDD 定义路径，verification 定义完成标准。三者缺一，Codex 都容易跑偏。",[33,727,729],{"id":728},"_8-团队落地-checklist","8. 团队落地 Checklist",[14,731,732],{},"可以按这个顺序逐步引入：",[124,734,737,749,760,769,777,783,789,798,806,812],{"className":735},[736],"contains-task-list",[127,738,741,745,746,748],{"className":739},[740],"task-list-item",[742,743],"input",{"disabled":310,"type":744},"checkbox"," 根 ",[24,747,26],{},"：项目速览、铁律、目录契约、命令、风格锚点",[127,750,752,754,755,757,758],{"className":751},[740],[742,753],{"disabled":310,"type":744}," 关键模块 nested ",[24,756,26],{}," \u002F ",[24,759,225],{},[127,761,763,765,766,768],{"className":762},[740],[742,764],{"disabled":310,"type":744}," ",[24,767,30],{},"：approval、sandbox、project doc limit",[127,770,772,765,774,776],{"className":771},[740],[742,773],{"disabled":310,"type":744},[24,775,231],{},"：TDD、新模块、内部框架、commit style",[127,778,780,782],{"className":779},[740],[742,781],{"disabled":310,"type":744}," Hooks：危险命令、secrets 扫描、最小 typecheck",[127,784,786,788],{"className":785},[740],[742,787],{"disabled":310,"type":744}," MCP：GitHub \u002F 任务系统 \u002F docs \u002F DB 只读",[127,790,792,765,794,797],{"className":791},[740],[742,793],{"disabled":310,"type":744},[24,795,796],{},".codex\u002Fagents\u002F","：code explorer、CI investigator、test runner",[127,799,801,803,804],{"className":800},[740],[742,802],{"disabled":310,"type":744}," PR review 准则写进 ",[24,805,26],{},[127,807,809,811],{"className":808},[740],[742,810],{"disabled":310,"type":744}," 高风险业务改动引入 spec-driven change",[127,813,815,817],{"className":814},[740],[742,816],{"disabled":310,"type":744}," 首轮小任务校准，把偏差回写进规则",[14,819,820,821,823],{},"不要一口气全上。最推荐的顺序是：根 ",[24,822,26],{}," → 项目 config → 1-2 个 Skill → 最小 hooks → PR review → spec-driven。每一步都能带来真实收益。",[14,825,826,828],{},[144,827,146],{}," 团队落地不是装一堆插件，而是逐步把隐性工程判断固化进工具链。",[33,830,831],{"id":831},"总结",[14,833,834],{},"个人用 Codex，看的是“它能不能帮我快一点”。团队用 Codex，看的是“它能不能按我们的方式稳定交付”。",[14,836,837],{},"这需要三层东西：",[243,839,840,848,854],{},[127,841,842,42,845,847],{},[144,843,844],{},"规则层",[24,846,26],{},"、config、hooks，定义边界和铁律。",[127,849,850,853],{},[144,851,852],{},"流程层","：Skills、TDD、review、verification，定义怎么做。",[127,855,856,859],{},[144,857,858],{},"语义层","：Spec \u002F OpenSpec，定义到底做什么、哪些不做、怎么验收。",[14,861,862],{},"Codex 不会天然理解团队历史、领域不变量和架构品味。资深工程师的价值，就是把这些隐性判断翻译成它能执行的规则、流程和验收标准。",[14,864,865],{},"当这套系统跑起来，Codex 才不只是每个人私用的效率工具，而会变成团队知识管理和工程交付的一部分。",[14,867,868],{},[869,870,872],"a",{"href":871},"\u002Fblog\u002F","返回博客列表",[874,875,876],"style",{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}",{"title":165,"searchDepth":289,"depth":289,"links":878},[879,880,881,882,883,884,885,892,893],{"id":35,"depth":289,"text":36},{"id":150,"depth":289,"text":151},{"id":187,"depth":289,"text":188},{"id":264,"depth":289,"text":265},{"id":343,"depth":289,"text":344},{"id":447,"depth":289,"text":448},{"id":665,"depth":289,"text":666,"children":886},[887,888,889,890,891],{"id":673,"depth":295,"text":674},{"id":683,"depth":295,"text":684},{"id":693,"depth":295,"text":694},{"id":703,"depth":295,"text":704},{"id":713,"depth":295,"text":714},{"id":728,"depth":289,"text":729},{"id":831,"depth":289,"text":831},"AI\u002FLLM","2026-06-18","md",{},"\u002Fblog\u002Fcodex-team-adoption",{"title":5,"description":16},"blog\u002Fcodex-team-adoption",[902,903,904,905,906],"Codex","团队协作","TDD","OpenSpec","AI编程","YlVeTDSNl2RmsqBBVe5eQBYdJwZP0f4upsH4mdJHLYU",1781797590751]