夜雨聆风摘要
一个 Ask HN 帖子收集到 165 位开发者的 AI 编码工具链配置。四个方向一致的信号：多工具组合是常态，context 管理是真正的产出瓶颈，spec-first 沉淀为可复用方法论，工程师核心技能从"写对代码"迁移到"架构系统"。
不是赢家通吃，是组合拳
一个 Ask HN 帖子问"你的 AI 开发技术栈是什么"，165 条回答给出的第一个信号是：没有人只用一个工具。
nickdichev 的回答最精炼："Claude Code 是剑，Codex 是盾。"AndreVitorio 的配置更具体：Claude Code 和 Codex 跑 Conductor 做 worktree 并行，处理中大型任务和 code review；Cursor 加 Composer 2.5 处理小改动和手动编辑。三份 20 美元月订阅，按场景切换。willyv3 的三层结构更极端：Cursor 做日常编码，一个带持久记忆的 agent 处理异步事务（邮件分拣、日历准备、上下文恢复），Claude API 做一次性重推理。
这组回答反映的实际状况是：不同工具在不同环节有各自的优势区间，开发者在实践中自发形成了分工。Claude Code 擅长长时间、跨文件的重构任务；Codex 的挑剔气质适合做 review；Cursor 在小范围编辑和 IDE 集成上体验最顺滑。没有哪个工具在所有场景下都最优，组合使用不是"还没选定工具"，而是有经验的开发者在用工具的特长匹配任务的特征。
Stavros（stavros.io）把这种分工推到了极致。他用 OpenCode 配置了三个 agent 角色：架构师用 Opus 4.6 做规划和设计决策，开发者用更便宜的 Sonnet 4.6 写实现代码，一到三个 review agent 分别用 Codex、Gemini 和 Opus 独立审查 diff。他的理由很直接：同一个模型审查自己写的代码基本无效——"让一个模型 review 自己的代码，它倾向于同意自己"——换一个模型做 review 等于引入第二双眼睛。按他的描述，Codex 偏执、较真，不适合写代码但恰好适合挑毛病；Gemini Flash 有时能发现其他模型没看到的方案。不同模型的弱点彼此错开，质量就出来了。
context 退化才是真瓶颈
killamdiaz 在帖子中提了一个被广泛认同的问题："有多少人发现 context 管理已经变成了比模型质量更大的瓶颈？最大的失败通常不是因为模型写不了代码——而是因为模型丢失了对项目约定、先前决策、某段代码为什么这样写的记忆。"
这不是个别感受。sermakarevich 用 Claude Code 插件实践 spec-driven development 已有四个月，核心动机之一就是控制 context 膨胀："把所有需求固化到 spec 文件里，每个子任务实现完就重启 session。这样 session 的 context 始终聚焦在单个任务上。"itake 的工作流更直白地暴露了这个矛盾：先用 spec-kit 做 spec-driven development，然后"退化到多个 session 分别调试各种问题，直到完成"。"退化"这个词本身说明，开发者知道 spec-first 是对的，但 context 膨胀会在项目推进中逼着人放弃理想流程。
acemarke（Redux 维护者 Mark Erikson）花了大量篇幅描述他如何与 context 退化搏斗。他的方案包括：一个缓存文件读取的 MCP 工具（cachebro），文件没变就返回"未改变"而非重新注入全文；OpenCode 的 Dynamic Context Plugin 让 agent 主动压缩最近的工具调用和讨论，而不是等到 context 爆了再做整体压缩；每条子任务完成时执行 /progress 和 /subtask-complete 命令，把成果写入持久化的 Markdown 文件，让新 session 可以读取前序工作成果而不依赖 session 内的 context。他观察到，agent 主动压缩近期内容的效果远好于一次性"总结整个 session"的压缩——后者会丢失太多关键细节。
这些实践指向同一个判断：模型的编码能力已经够用，瓶颈转移到了 context 的保质期上。一个 agent session 持续运行几万 token 之后，输出质量会下降，不是因为模型变笨了，而是因为早期写入的约定、决策和约束在 context 中被稀释了。所有成熟的实践——spec 文件、分阶段重启、持久化进度记录——本质上都是在解决同一件事：把关键信息从 session 的易失性 context 里提取出来，变成不依赖 session 的持久文档。
spec-first 从实践沉淀为方法论
spec-first 在这个帖子里不是一个笼统的"先想清楚再动手"建议，而是有具体工具支撑的工作流。
GitHub 的 spec-kit 仓库有超过 11 万 star，定位是"spec-driven development 的入门工具包"。sermakarevich 描述的流程是：先用 agent 做调研和信息收集，写出详细 spec；再把任务拆解为子任务，每个子任务单独写 spec；逐个实现，每个子任务完成后重启 session——因为所有需求已经固化在 spec 文件里，新 session 不需要记住前序对话。dempedempe（承包商，做 AWS 和 web 应用）的五阶段工作流类似但更结构化：discovery、implementation planning、implementation、verification、review，每个阶段的产物写入 .agents/plans/{plan-name}/ 目录，全部用 Markdown 存储，对具体 agent 不做绑定，阶段产物一旦写完即不可变。
这两个实践有一个共同的隐含假设：把"理解需求"和"实现需求"拆到不同 session 里做，效果更好。前一个 session 的核心工作是消除歧义和做出决策，后一个 session 的工作是在决策明确的条件下执行。决策阶段需要人高度参与，执行阶段对 context 的要求反而更低——因为不需要在 session 内保留"为什么"的讨论，只需要保留"做什么"的规格。
Stavros 的三 agent 架构本质上也在做同一件事。架构师 agent 和人对话、做决策、输出计划文件，开发者 agent 拿到计划文件直接执行。计划文件就是 spec。他不把决策和实现混在同一个 session 里，也不混在同一个 agent 里。按他的说法，"这让我仍然知道函数级别以上的每一个决策，并且可以在后续运行中使用这些知识。"
技能迁移：从写代码到架构系统
Stavros 文章中有一段判断值得完整引用："我的工程技能并没有变得没用，它们只是转移了：我不再需要知道如何正确地写代码，但正确地架构一个系统变得比以往任何时候都重要得多。在不熟悉底层技术的项目上（比如移动应用），代码仍然会迅速变成一堆糟糕的选择。但在熟悉技术栈的项目上，这种情况到现在还没有发生过，即使代码量达到数万行。"
他把模型能力的演进描述为一个审查粒度不断上移的过程：早期 GPT 时代需要逐行审查代码；后来只需要审查函数级别；现在大部分审查在"整体架构"层面就够了。前提是工程师自己能做架构层面的判断。当模型基于对 codebase 的不完整理解推荐了一个"在另一个项目里很好、但在当前项目里不适用"的方案时，只有理解全局的工程师才能拦截。
acemarke 的工作流是这种技能迁移的另一个样本。他用了大量篇幅描述自己的定制化配置：一个解析 Bash 命令并自动审批安全命令的 OpenCode 插件（他为此维护了一个 OpenCode 的本地 fork）；一个独立的 dev-plans 仓库用于存储跨 session 的项目文档和工件；专门编写的 /context、/progress、/subtask-complete 等命令来管理父子 session 之间的信息传递。他的原则是："我掌控全局。我知道自己在做什么、想达成什么。我决定任务是什么、怎么做、什么时候从研究切换到实现、什么时候任务算完成。"这种角色定位已经不是"写代码的人"，更接近于"技术总监在指挥一个初级工程师团队"。
coffeecoders 描述了一个更保守但方向一致的迁移："slow code"方式，把 AI 当设计伙伴而非代码生成器。写测试、自己写代码、然后把代码交给 AI 检查边界情况、验证效率。架构问题会"先跟 AI 来回讨论四五次，不断反驳它的假设"。AI 在这里扮演的角色是史上最好的橡皮鸭。
反面声音同样值得听
chrismorgan 的回答在 165 条中显得格外突出："none。我选择用老方式编程， foreseeable future 不会改变。"他的补充更有意思："如果我教一个人编程，我会积极劝阻他使用 AI——即使它看起来有帮助。前提是这个人想学编程，而不是只要结果。"
cadamsdotcom 走的是另一条路：不是不用 AI，而是拒绝所有主流的"增强"方式。他用 Claude Code 超过一年，建了一个 30 万行以上的 SaaS 代码库，但用的是"零 skills、零 MCP、零装饰"。他的"技术栈"是一组 Claude Code hooks，强制模型走 TDD 循环：写失败测试、看到失败（证明测试有效）、写代码让测试通过、看到通过、可选重构。agent 被确定性的状态机强制推过这个循环，写 Playwright 端到端测试来验证自己的工作。一年的开发中，他从未手动给模型一个浏览器。
这两个回答的共性是：它们都拒绝"让 AI 尽量多地生成代码"这个前提。chrismorgan 认为学习阶段这样做会削弱核心能力；cadamsdotcom 认为 AI 的价值在于被约束而非被放权。他们不代表主流，但在一片"多工具、多 agent、多 session"的讨论中，这些约束派的声音提供了另一种参照。
信源说明：本文素材主要来自 2026 年 6 月 5 日 HN 帖子"Ask HN: What is your (AI) dev tech stack / workflow?"（165 pts / 134 comments），已访问 HN Algolia API 获取原帖及评论全文。Stavros 的工作流描述来自其博客文章"How I write software with LLMs"（stavros.io，2026 年 3 月），acemarke 的配置和工作流来自其博客"My Thoughts on AI, Part 2: Agent Setup, Workflow, and Tools"（2026 年 5 月）。spec-kit 数据来自 GitHub API。所有引用均为原始英文评论的中文意译，未做逐字翻译。
