HN 社区 2026 年中 AI 开发生态调查：91 位开发者都在用什么工具栈？
2026 年 6 月 5 日，一位 HN 用户发起了「你的 AI 开发技术栈/工作流是什么？」的讨论，不到两天就收获了 106 个 upvote 和 91 条评论。从大型云平台的 Agent 编排到最朴素的「手写代码+浏览器助手」，从三 Agent 协作结构到零 AI 的纯粹主义——这篇文章整理了 HN 社区的六大典型 AI 开发工作流，并提炼出适合不同团队和个人的选型思路。
背景：为什么这个问题值得深挖？
2026 年年中，AI 编码工具已经进入了一个前所未有的多元化阶段。OpenCode、Claude Code、Codex、Pi、exe.dev、GitHub Copilot Agent、Mecha-AI……各类工具的定位差异越来越大。有的主打全托管的云 Agent 体验，有的坚持纯终端极简主义，有的走代码审查路线，有的则完全手工打造自己的 AI 工作流。
在这个「工具大爆炸」的时间点，看看真实的开发者群体都在用什么、踩过什么坑、沉淀了什么最佳实践，对于每一个开发者或团队来说都极具参考价值。
以下是对 91 条 HN 评论的系统性整理。
一、OpenCode 派：Batteries-Included 的云原生 Agent 编排
_”OpenCode + their Go subscription. Start with a nice batteries included setup, read Anthropic’s knowledge sharing, play and iterate, stay human in the loop.”_ — verdverm
核心工具链：OpenCode（CLI/Web）+ Go（订阅版）+ 多 Agent 协作
OpenCode 是目前 HN 社区中出镜频率最高的 AI 编码工具之一。它的「多 Agent 编排」能力是最被频繁提及的特性——多个 Agent 分工协作，覆盖不同阶段的任务。
典型工作流（stavros 方案）：
opencode --agent architect --model claude-opus-4 # 设计架构 opencode --agent developer --model sonnet-3.5 # 实现代码 opencode --agent reviewer --model gpt-4o # 审阅结果
Galanwe 的 tmuxinator 风格工作流：
Feature Branch Setup: ├── git worktree → 隔离分支环境 ├── zellij pane 1: OpenCode (编码 Agent) ├── zellij pane 2: Shell (手动操作) ├── zellij pane 3: Neovim (代码审查) └── zellij pane 4: inotify (自动测试)
关键洞察：OpenCode 用户往往不只使用一个 Agent，而是建立多 Agent 协作流程——先让架构 Agent 规划，再让开发 Agent 实现，最后让审阅 Agent 检查。这与单 Agent 的「一次性生成」模式有本质区别。
另一位用户 0xbadcafebee 补充了 Web 端的管理优势：
_”OpenCode. Despite its many shortcomings and constant bugs, it’s good enough for basic work. Use the web interface so you can switch around sessions easily.”_
二、Claude Code 极简派：一切从终端出发
_”Claude Code and/or Codex from Ghostty/Terminal. You don’t need to complicate it.”_ — emehex
核心工具链：Ghostty（终端）+ Claude Code + Markdown
Claude Code 的用户群体呈现出一种「工具极简主义」倾向——不依赖复杂的 IDE 集成或多云编排，而是让 AI 纯 CLI 与终端无缝配合。
nimonian 的 Gherkin Spec 工作流：
git worktree add feature/new-feature cd feature/new-feature claude "Write a Gherkin spec for user authentication" claude "Create actionable @todo from spec" claude "Implement story-1: login form"
RivoLink 的技能复用方案：
flow add "security-review" "Review this code for OWASP Top 10 vulnerabilities" leaf ./docs/architecture.md claude --skill security-review ./src/auth/ --output review.md
mkw5053 的「左移」质量策略：
_”Push as much as possible as far left in the SDLF: types → lint rules → tests → markdown docs. Improve the dev experience after every single PR.”_
Claude Code 用户群的共通点是：不追求 Agent 数量，追求单次交互的质量。先通过 types/lint/tests 建立质量护栏，再让 Agent 在护栏范围内自由发挥。
三、Pi/Codex 评审派对：AI 代码审查取代 AI 代码生成
_”MacOS, Ghostty, Neovim, Pi. I’m relatively new to Pi after using Codex pretty heavily.”_ — michaelmior
核心工具链：Neovim / Ghostty + Pi（代码审查 Agent）+ 传统编码
Pi（pi.dev）代表了一类与主流「AI 替你写代码」截然不同的理念——它不强求 Agent 直接生成代码，而是把 AI 定位为代码审阅搭档，在开发者手写代码的基础上提供智能审查和优化建议。
zackify 的自建 TUI + Pi 方案：
使用 Pi 的典型工作流：
开发流程： 1. 手写代码（纯 Neovim / IDE） 2. 运行 Pi 审查 → 获取改进建议 3. 选择性接受修改 4. 提交 → 继续下一段开发
与 OpenCode/Claude Code 生成式 AI 不同，Pi 工作流的核心理念是：开发者仍然控制代码的生产过程，AI 只是加速了审查和迭代环节。这种方式特别适合对代码质量有极高要求、或受组织合规政策限制不能完全依赖 AI 生成代码的团队。
四、自建派：完全掌控你的 AI 工作流
_”I wrote my own tooling around the raw LLMs: I tick files in Vim, those get concatenated into a prompt. Along with a feature request. Plus an instructions file that tells the LLM how to reply.”_ — mg
有一批开发者选择「不依赖任何现成 AI 编码工具」，直接从底层 LLM API 构建自己的 AI 开发辅助系统。
coffeecoders 的「慢代码」设计伙伴模式：
// 测试驱动开发 + AI 设计伙伴
// 1. 先写测试
describe('PaymentService', () => {
it('should handle idempotency correctly', async () => {
// 手写测试用例
});
});
// 2. 让 AI 审查测试设计
// 3. 自己实现代码
// 4. 让 AI 审查实现
// 5. 改进 → 循环
sermakarevich 的 Spec-Driven Development 插件：
_”I am using SDD implemented as a Claude Code plugin since Feb. The idea is to write detailed specs first using agent help doing research and interviews.”_
自建派的工作流归纳起来有三个共同特征：
- AI 是工具而非控制者——开发者主动控制流程，AI 只在选定的步骤中发挥作用
- 基础设施自主化——从 Prompt 拼接器到文件管理系统，自己维护全套工具链
- 质量和透明度优先——每一步 AI 的介入都是显式的、可审计的
五、企业受控派：在安全合规与 AI 效率之间找平衡
_”Lead Dev for a Security Company with a very strict AI policy. Mostly hand-coded, using an agent in the browser when necessary.”_ — gottagocode
核心工具链：手写代码 + 浏览器内 Agent（Claude/ChatGPT）+ Copilot（若允许）
企业环境中的开发者面临一个独特的困境：AI 编码工具可以大幅提升效率，但安全策略、合规要求、数据隐私限制了许多主流 AI 工具的使用。
KronisLV 的企业上下界方案：
最简单的工具组合：
- Claude Desktop（含 Claude Code）— 对 Anthropic 系列
- ChatGPT 应用（含 Codex CLI）— 对 OpenAI 系列
- 企业内部 IDE + Copilot（如果安全和合规允许）
GitHub Copilot 企业用户（outside1234）：
gh copilot audit --severity high gh copilot docs --coverage-report gh copilot refactor --pattern "error-handling"
对于不想被任何单一厂商锁定的企业开发者，多提供商策略是关键——备好 Claude 和 OpenAI 两套工具，根据任务类型和合规要求切换。
六、「不使用派」：零 AI 也是一种选择
_”None. I choose to program the old-fashioned way, and do not anticipate this changing in the foreseeable future.”_ — chrismorgan
核心工具链：传统编辑器 + 传统工具（无 AI 辅助）
这一群体在 91 条评论中虽然数量最少，但他们的声音值得认真对待。chrismorgan 的评论获得了一定数量的认可回复（upvotes），说明 HN 社区中相当一部分开发者认同这种选择：
_”If it becomes commercially unviable, well, I may no longer be interested in the field anyway.”_
这不是对 AI 的抵触或恐惧，而是一种经过深思熟虑的主动选择——不是每个开发者都认为「有了 AI 就必须用 AI」。
总结：HN 社区 AI 开发工作流的六大趋势
从 91 条评论中，可以提炼出以下趋势：
| 工作流类型 | 核心工具 | 适合场景 | 关键优势 |
|---|---|---|---|
| OpenCode 多 Agent 编排 | OpenCode + Go | 复杂项目、团队协作 | Agent 分工、云端管理 |
| Claude Code 极简终端 | Ghostty + Claude Code | 独立开发者、快速迭代 | 简洁高效、零配置 |
| Pi/Codex 代码审查 | Neovim + Pi | 质量敏感型项目 | 保持开发者控制权 |
| 自建 AI 工作流 | 自制脚本 + LLM API | 高度定制化需求 | 完全可控、无供应商锁定 |
| 企业受控 | Copilot / 浏览器 Agent | 受合规限制的环境 | 合规 + 效率的平衡 |
| 零 AI 纯粹主义 | 传统工具链 | 特定项目/偏好 | 完全的传统控制感 |
两个值得关注的趋势：
- 多 Agent 协作正在取代单 Agent「一次性生成」：不管是 OpenCode 的三 Agent 组合（stavros），还是 zellij 中的多 pane 布局（Galanwe），都表明「一个 Agent 写出所有代码然后人工改 Bug」的模式正在被更精细的 Multi-Agent 流水线取代。
- 「AI 审阅者」正成为新常态：无论是 Pi 的专职审查、Copilot CLI 的自动审计、还是自建工作的 prompt 审查系统，AI 作为代码审查者（而非代码生产者）的角色正在获得越来越多开发者的认可——这与之前的 AI 即代码生成器的主流认知有明显不同。
给读者的建议：
- 如果你是独立开发者：从 Claude Code + 终端开始，先跑通一个最简单的闭环
- 如果你在创业团队：尝试 OpenCode 的多 Agent 编排，把架构设计和代码实现分开
- 如果你在受监管的企业：建立多提供商策略（Claude + OpenAI + Copilot），用审查模式替代生成模式
- 如果你偏爱掌控感：从 LLM API 开始自建最小工作流，只编排你真正需要的步骤
本文基于 HN 用户 dv35z 发起的 Ask HN 讨论（ID: 48413629）整理而成。91 条评论覆盖从 DevOps 工程师到安全架构师的广泛视角，排名和引用已尽可能保持原文意图。