Y Combinator 总裁 Garry Tan 开源了他的私人武器库--GStack。
这不是又一个 AI 编程插件。这是一个完整的"Markdown 即代码"软件工厂，让一个人拥有 20 人工程团队的交付能力。
"It's just markdown"
这句看似平淡的话，藏着 LLM 时代最激进的编程范式转移。
| 传统代码 | Markdown 即代码 |
|---|---|
| 写给机器执行 | 写给 LLM 理解 |
| 语法严格、边界封闭 | 语义丰富、上下文开放 |
| 人类翻译需求为指令 | 人类描述意图，LLM 生成指令 |
关键洞察：当 LLM 成为执行层，人类的核心产出从"精确指令"变成了"清晰意图"。而 Markdown--这个为人类可读而生的格式--恰好成了意图表达的最佳载体。
GStack 的 15 个专业角色，全部以 .claude/skills/ 目录下的 Markdown 文件存在。Claude Code 自动发现、调用、执行。
Think → Plan → Build → Review → Test → Ship → Reflect每一步都是强制关卡，绝不跳过。这才是"一人团队"能持续高质量交付的秘密--不是取代流程，而是自动化流程。
| 命令 | 角色定位 | 核心能力 |
|---|---|---|
/office-hours | YC 合伙人 | 想法重构、MVP 定义、风险识别 |
/plan-ceo-review | CEO | 战略定位、商业价值、优先级 |
/plan-eng-review | 工程经理 | 架构设计、依赖分析、时间估算 |
/plan-design-review | 设计总监 | 用户体验、交互流程、视觉规范 |
/design-consultation | 设计系统专家 | 组件库、样式体系、Figma-like 描述 |
/design-review | 设计 QA | 代码级设计审计、一致性检查 |
/review | 资深工程师 | 代码审查 + 自动修复 |
/investigate | 调试专家 | 系统性根因分析 |
/qa | 测试工程师 | 端到端测试 + 自动修复 + 回归验证 |
/qa-only | 保守派测试 | 只跑测试，不自动修复 |
/ship | 发布工程师 | 测试 → PR → 部署全流程 |
每一个 / 背后，都是结构化提示词 + 领域知识 + 输出规范的封装。
.claude/skills/*.md 成为新的 API 定义。不需要写代码调用 AI，写 Markdown 描述能力即可。
不再雇佣"全栈工程师"，而是按需调用"CEO 视角""设计总监视角""QA 工程师视角"。认知劳动的颗粒度被彻底细化。
GStack 的真正价值不是单次生成，而是可复用、可迭代、可传承的工作流。你的 .claude/skills/ 目录，就是团队的数字 DNA。
MIT 许可，GitHub 直接可用：garrytan/gstack
Garry Tan 的开源不是慷慨，是押注--押注这种范式会成为基础设施。当越多人使用、 fork、改进，Markdown 即代码的标准就越稳固。
如果编程的终极形态是"用自然语言描述意图"，那我们还需要学习传统编程吗？
GStack 给出的答案是：需要，但方式变了。你不再写 for 循环，但你需要理解循环的本质；你不再调 API，但你需要设计 API 的边界。
Markdown 即代码，不是降低门槛，而是转移门槛--从语法记忆转向系统设计，从实现细节转向意图表达。
你准备好把自己的技能封装成
.md文件了吗？
加入讨论
这15个斜杠命令看得我头皮发麻，/office-hours 和 /plan-ceo-review 这种角色封装太细了。不过好奇实际用起来会不会有上下文爆炸的问题？毕竟一个复杂项目要串好几个角色，token 烧起来估计很酸爽 😂
“写给LLM理解”这个点太戳我了。以前写代码要纠结分号括号，现在写Markdown描述清楚就行，感觉门槛真的降了好多。不过有点担心，以后 junior 工程师是不是更难成长了？直接调用 /review 谁还自己啃代码规范啊😂
看到”Reflect”这一步突然有点感触。以前项目上线就完事了，现在AI逼着你复盘，这习惯养好了比啥都强。不过好奇这个反思环节是自动生成报告还是真能让人停下来想想？
GStack 这个命名有点东西，Stack 暗示了可堆叠、可组合，比单纯的 agent 框架高一个维度。不过 15 个角色全是 Claude 生态，要是想换模型是不是得重写一堆 prompt？
好家伙，七步闭环里”Reflect”放最后简直是反人性设计——我自己项目复盘从来都是能拖就拖。不过转念一想，AI盯着的话确实不好意思偷懒了，这算赛博监工还是赛博自律？🤔
说实话看到”一人拥有20人工程团队”这种话我第一反应是老板狂喜🙂 但细想下来，这15个角色不就是把原来20个人的扯皮会议变成了AI内部循环吗，至少不用等排期了。唯一担心的是，以后出了问题找谁背锅？找Claude吗😂
有点好奇这个 `.claude/skills/` 的目录结构，如果我把自己的业务知识写成 Markdown 丢进去，Claude 真的能自动识别调用顺序吗？还是说需要严格遵循某种命名规范 🤔
Markdown 当代码用这事儿，让我突然想到以前用 Jupyter Notebook 的感觉——也是文档和代码混在一起，但那时候还得自己跑。现在倒好，LLM 直接帮你执行了，就是不知道调试的时候找 bug 是在 Markdown 里找还是生成的代码里找🤔
这”文件即接口”的说法让我愣了一下，仔细想想还真是——以前调API要写client，现在扔个Markdown进去就算对接了。不过有个实际问题：这些.md文件版本冲突了怎么办？两个人同时改了一个角色的prompt，Claude会不会精神分裂啊😂