AI Coding

我最近在整理一套 spec-driven 的 AI coding 流程，叫 agent workflow。 它解决的不是“哪个模型写代码更强”，而是另一个更实际的问题：需求、实现、验收如果都挤在同一个长对话里，最后很容易分不清到底是 spec 模糊、实现跑偏，还是验收只是在迁就已经写出来的代码。 agent workflow 的做法很简单：把角色拆开。 Claude 负责把模糊需求拷问成 spec 和可执行 issue，实现时负责钉死 spec、复审和验证；写代码的活交给 Codex 的 gpt-5.6-sol，验收判定也由它在另一个干净线程里做。两个模型之间不靠聊天记录交接，只靠两样东西：GitHub Issues 和仓库里落盘的文档。 整条链画出来是这样： 入口（三选一） 一般需求 → /grill-with-docs 烤问对齐，术语进 CONTEXT.md，决策进 ADR 雾大的活 → /wayfinder 在 tracker 上建图，多会话逐张解雾 外部 issue → /triage 状态机分诊，产出 ready-for-agent │ Claude：把想清楚的东西固化成规格 /to-spec → spec issue：目标、非目标、验收标准、测试 seam /to-tickets → 垂直切片 tickets，每张标 blocked-by │ ├─◄ 交接面：GitHub Issues + repo docs │ 不是聊天记录。所以每一步都能换会话、换模型 ▼ /implement-codex #N Claude 钉死 spec，在约定 seam 写红测，选推理档 │ brief：issue 原文 + 红测 + 仓库约定 + 验证命令 ▼ Codex 冷启动线程：写代码、跑测试。不 commit、不 push │ 工作树 diff，这是它唯一的输出 ▼ Claude 不信它的汇报，自己跑 typecheck 和全量测试 /code-review 审 diff ① Claude 审 Codex 的代码 commit 引用 #N。到此为止不 push、不关单 │ ▼ /accept-issue #N（硬规则：必须新会话，不能是实现会话） Codex 法官：跑 verify 入口，用测试没用过的输入实测行为， 逐条裁决并附上命令和输出 ② Codex 审 Claude 的 spec Claude 书记员：只查形式。缺证据就打回，不脑补，不推翻裁决 │ ├─ 通过 → /land-issue #N：push、留验收摘要、close └─ 不通过 → 写回 issue 保持 open，交给下一个冷启动会话 跨模型检查是双向的： ① code-review 阶段，Claude 审 Codex 写的代码 ② 验收阶段，Codex 审 Claude 写的 spec 下面提到的 skill 我都放在这个仓库里，多台机器之间同步用：https://github.com/sleepingF0x/skills ...

Anthropic 最近发了一篇文章，讲 Claude Code 怎么在大代码库里工作。它里面最有用的点不是某个 prompt 技巧，而是一个更工程化的判断：Claude Code 在大仓库里好不好用，很大程度取决于仓库本身有没有被整理成 agent 能导航的环境。 Claude Code 不是先把整个仓库做成一个中心化索引，再从索引里召回答案。它更像一个坐在你电脑前的开发者，会读文件、搜关键词、看目录、跟引用、跑命令。这个模式的好处是它看到的是本地最新代码，不太会被过期索引误导；坏处是你不能只丢一句“帮我改一下支付逻辑”，然后指望它在几十万行代码里自己精准落点。 在大代码库里用 Claude Code，重点是减少它的无效探索。 从相关目录启动 如果是 monorepo，不要每次都从仓库根目录启动。改某个服务，就先进入那个服务目录；改某个 package，就从 package 目录启动。 Claude Code 仍然可以向上读取父级 CLAUDE.md，但它的第一视角会更接近当前任务。搜索范围变小，读到的文件更相关，后面跑测试、lint、build 也更容易收窄。 可以把日常入口做成 alias： alias c-api='cd ~/repo/apps/api && claude' alias c-web='cd ~/repo/apps/web && claude' alias c-worker='cd ~/repo/services/worker && claude' 这种小动作比写一大段 prompt 更稳定。 写分层 CLAUDE.md 根目录的 CLAUDE.md 只放全局信息：系统大概怎么分层、关键目录负责什么、通用代码规范、绝对不能踩的坑。 不要把它写成百科全书。根文件每次都会进上下文，越长越容易把真正有用的信息挤掉。 更适合的结构是分层： repo/ CLAUDE.md # 全局架构、通用约定、关键禁忌 apps/web/CLAUDE.md # 前端启动、测试、路由、组件约定 apps/api/CLAUDE.md # API 测试、数据库迁移、错误处理约定 services/worker/CLAUDE.md # 队列、重试、部署前检查 子目录里的 CLAUDE.md 要写具体命令，比如： ...

你不知道的 Agent：原理、架构与工程实 原文链接 <https://x.com/HiTw93/status/2034627967926825175> 一个 Agent 系统怎么才能跑得稳 Agent 的最小运行原理 Workflow 和 Agent 的区别 控制流的几种常见模式 Harness、验证和执行边界 上下文工程与压缩缓存 工具设计 记忆与长任务续跑 多 Agent 协作 评测、追踪和安全 用具体系统把这些原则落地 你不知道的 Claude Code：架构、治理与工程实践 原文链接 <https://x.com/HiTw93/status/2032091246588518683> 怎么把Claude真正用进日常开发，而不是只把它当成一个会写代码的聊天工具 Claude Code 的六层结构与核心循环 上下文为什么会乱，以及该怎么治理 Plan Mode、Compact、HANDOFF 这些机制怎么配合使用 Skills 应该怎么写，描述符、正文和 supporting files 怎么分工 Tools 和 Hooks 应该怎么设计，哪些能力该交给哪一层 Subagents 的真正价值是什么，什么时候该用，什么时候不该用 Prompt Caching 怎样影响系统架构、工具顺序和模型切换 验证体系、命令体系和常用工作流怎么搭 CLAUDE.md 应该写什么，不该写什么 最后回到项目实践，给出一套可落地的工程布局 你不知道的 AI Coding：非技术人的上手、场景与实战 原文链接 <https://x.com/HiTw93/status/2048230976447557787> 非技术同学怎么把 Claude Code 真正用起来，而不是停在对话框 AI 终端并不是程序员专属，关键是先跨过第一步 非技术同学也需要懂一点框架、Git、报错和代码结构 Claude Code 更像通用 Agent，写代码只是最早的入口 最适合交给 AI 的，是目标清楚、结果好验收的任务 从 software for one 开始，先做只服务自己的小工具 需求要写具体：问题、范围、异常、验收标准都要落到数字和场景 复杂任务先用 Plan Mode，确认方案后再让它执行 改代码前用 Git 留检查点，排错时先找根因再动手 CLAUDE.md、Skill、Memory 是把个人习惯沉淀成工作流的关键 截图、拆小任务、重启对话和安全边界，是新手最容易忽略的基本功