嗨，我是辉哥，一个致力于使用 AI 技术搞副业的超级个体
GStack 拆解：角色化认知隔离，让AI不再自己审自己
GStack用42个纯Markdown定义的Skill，搭起了一个完整的虚拟工程团队。每个Skill对应一个专业角色，有自己的思维方式、工作流程和评价标准。
一、传统AI编程的根本缺陷
所有用AI写代码的人都遇到过同一个问题：AI写的代码看起来完美，自己审查也说没问题，上线就出bug。
这不是能力问题。同一个大脑没法同时当好创造者和批判者。AI完成代码创作的那一刻，会自动进入"自我辩护"模式------下意识为每一行代码找合理性，而不是找问题。这种认知偏差人也有，但AI的合理化能力比人强太多了。
更深层的原因来自模型机制本身：大模型的注意力机制决定了，同一段上下文中，前面生成的内容会对后续审查产生强偏向。模型会优先关注已生成内容的合理性，而非潜在问题。这不是态度问题，是先天机制缺陷，只有通过物理层面的上下文切割------独立角色、独立会话------才能解决。
还有第二个缺陷：没有决策分层。同一个大脑既要做产品决策，又要做架构设计，还要写代码测代码。产品思维、工程思维、测试思维是三种不同的认知模式，混在一起的结果是AI非常高效地做了很多错误的事。
GStack的洞察就在这里：AI不是一个万能助手，而是一群可以随时切换的专家大脑。规划不是审查，审查不是测试，产品品味不是工程严谨。把这些认知模式强行塞进同一个上下文，只能得到平庸的结果。
二、三个底层支柱
GStack采用完全本地化的三层轻量化架构，所有逻辑在用户设备上执行，不需要云端服务。它的重点不是更强的代码生成，而是认知隔离和角色切换的基础设施。
技能层：纯Markdown定义的可执行角色系统
这是GStack的核心资产，也是它区别于其他框架的地方。每个Skill对应一个独立的Markdown文件，包含角色定位、核心指令、执行流程、检查清单和输出规范。
技能文件的标准结构：
markdown
# /skill-name
## 角色定位
一句话定义这个角色的目标和不可逾越的边界。
## 核心指令
这个角色必须遵守的铁律，优先级高于所有其他指令。
## 执行流程
严格按照步骤执行，不能跳过任何一步。
## 检查清单
完成所有步骤后，必须逐一核对这些问题。
## 输出规范
明确规定输出的格式和必须包含的内容。这种设计的思路是：用文本的精确性约束大模型的随机性。和主流Agent框架的"命令式代码工作流"不同，GStack走声明式路线------不硬编码每一步的执行顺序，只声明角色的目标、边界和准则，由大模型自主推导执行步骤。僵化的代码工作流只能适配固定场景，而软件工程没有两个完全一样的需求，声明式的角色定义才能应对复杂的真实开发场景。
纯Markdown有三个优势：完全透明，5分钟就能看懂一个Skill的全部逻辑，没有黑盒；无限可定制，不需要写代码，修改文本就能调整角色行为；天然可沉淀，Skill支持Git版本化管理，团队可以沉淀自己的角色规范和最佳实践，形成可复用的"AI角色资产库"。
持久化浏览器守护进程：给AI装上真实的眼睛
这是GStack最拿手的技术创新，解决了AI"只能看代码，不能看产品"的问题。之前所有的AI工具都只能静态分析代码，不知道代码跑起来到底什么样。
实现原理：GStack内置一个基于Bun和Playwright的轻量级HTTP服务器，启动一个持久化的Chromium浏览器实例。Claude通过本地HTTP API与浏览器交互，发送指令并接收结果。
几个关键设计点：
- 状态持久化：Cookie、会话数据、打开的标签页在多个命令之间保持不变，登录一次就能跑所有测试
- Ref元素定位系统：不使用脆弱的CSS选择器，而是基于无障碍树生成唯一引用（@e1、@e2），支持Shadow DOM和有CSP限制的网站。它不依赖DOM结构和类名，前端组件重构、样式改版都不会导致定位失效，这是它能用在生产环境测试的前提
- 毫秒级响应：首次冷启动约3秒，后续每条命令的交互延迟100-200毫秒
这个设计让AI第一次能像真实用户一样使用产品：点击按钮、输入文字、截图页面、验证交互效果。据GStack社区用户统计，引入真实浏览器测试后，前端交互类bug的发现率平均提升370%。
GBrain持久化内存系统（v0.16.0新增）
这是最新版本最大的架构升级，解决了大模型"健忘"的问题。GBrain是一个本地向量数据库和知识管理系统：
- 自动索引整个代码库，支持自然语言查询任何代码片段
- 跨会话保存所有项目决策、讨论记录和最佳实践
- 记住你的个人偏好和编码风格，不需要每次重复解释
- 支持多机器同步，在不同设备上保持一致的项目状态
和普通的"片段级代码RAG"不同，GBrain是项目级的持久记忆：不止检索代码片段，还会沉淀所有架构决策、团队约定、历史踩坑记录，像伴随项目全生命周期成长的"数字技术负责人"。技术上采用增量索引，代码变更时只更新变动部分，本地运行不会消耗大量资源。后面提到的/codex、/retro、/learn等协作类Skill，底层都基于GBrain构建。
三、全量Skill总览
GStack的42个Skill按软件工程标准流程分为10大类，搭成了一个职能完整的虚拟工程团队。不需要记住所有命令，先建立整体框架，再按需深入。
| 大类 | Skill | 定位 | 对应角色 |
|---|---|---|---|
| 产品规划 | /office-hours、/plan-ceo-review、/plan-eng-review、/plan-design-review、/plan-devex-review | 从想法到可执行计划 | 产品经理、CEO、设计总监、工程总监 |
| 设计 | /design-consultation、/design-shotgun、/design-html、/design-review | 从风格定义到像素级代码 | UI设计师、UX设计师、前端开发 |
| 开发 | /autoplan、/review、/ship、/land-and-deploy | 从任务拆分到代码合并 | 后端开发、前端开发、发布工程师 |
| 质量保证 | /qa、/qa-only、/benchmark、/canary | 从功能测试到性能测试 | 测试工程师、性能工程师 |
| 安全 | /cso、/guard、/careful | 从代码审计到实时防护 | 安全工程师、首席安全官 |
| 调试 | /investigate | 解决难以复现的系统问题 | 资深调试专家 |
| 浏览器 | /browse、/scrape、/skillify、/setup-browser-cookies | 让AI与真实世界交互 | 通用工具集 |
| 部署 | /setup-deploy、/land-and-deploy | 一键配置环境到自动化部署 | 运维工程师、DevOps |
| 文档 | /document-generate、/document-release、/make-pdf | 自动生成和更新所有文档 | 技术文档工程师 |
| 团队协作 | /retro、/learn、/freeze、/unfreeze、/health、/spec、/codex | 项目管理和知识管理 | 项目经理、技术负责人 |
开始之前，先建立这几个认知：常用的只有10个左右，80%的场景只需要最核心的10个，剩下的都是特定场景的补充；不需要一次性全用上，从最简单的/qa和/review开始就行；每个Skill都是独立的，可以单独用任何一个，比如只用/design-html转设计稿，其他用原来的工具；重点是理解原理而不是死记命令，理解了原理你甚至可以自己写出更好的Skill。
新手三步上手：入门只用 /review + /qa，不改变现有流程，先提升代码质量；进阶加入 /plan-ceo-review + /plan-eng-review，在写代码前把需求和架构想清楚；全流程接入部署、文档、浏览器等Skill，搭起完整的虚拟工程团队。
四、10个最常用Skill
从42个Skill中选出最常用、最贴合角色化隔离价值的10个，逐个讲解设计原理和解决的问题。
/office-hours：YC合伙人的一对一咨询
所有项目的入口。它的价值不是给你答案，而是帮你避免问错问题。
大多数人失败不是因为代码写得不好，而是因为解决了一个根本不存在的问题。我们总是急于给解决方案，却从来没有真正理解过问题本身。YC在过去18年从几千个创业项目中总结出一个规律：只要能清晰地回答六个问题，项目成功率就会提升一个数量级。/office-hours的设计就是强制你回答这六个问题，少一个都不能进入下一步。
提示词设计：
你是Garry Tan，YC的CEO。你不会直接给我答案。你会一次只问我一个问题，直到我真正理解我要解决的问题。不要跳跃，不要同时问多个问题。
它不会迎合你的想法，只会不断挑战你的假设。不会被"技术上很酷"的东西迷惑，只关注用户价值。很多开发者反馈，和/office-hours聊10分钟，就能让自己对产品的理解提升一个层次。
/plan-ceo-review：最敢说"不"的产品经理
GStack里最有个性的Skill。它是唯一一个会主动告诉你"这个功能不值得做"的AI工具。
开发者总是在做很多看起来不错但没用的功能，浪费了大量时间。据统计，软件产品中80%的功能从来没被用户使用过。大多数AI工具的设计目标是帮你完成你想做的事，而/plan-ceo-review的设计目标是阻止你做不该做的事。
提示词设计：
你的工作不是帮我完善计划，而是帮我砍掉计划。你要怀疑一切。你要假设我提出的所有功能都是不必要的，除非我能证明它的价值。如果有疑问，就说不。
三个决策立场：扩展------你的想法太小了，真正的机会比你想象的大10倍；保持------范围是对的，现在把它做扎实，不要加额外功能；缩减------砍掉所有不必要的功能，只保留能解决核心痛点的那个。
它最经典的回答是："你不需要做这个。用户真正需要的是X，而不是你想做的Y。"这是其他AI工具永远不会说的话。
/plan-eng-review：严谨的工程总监
它的目标不是设计完美的架构，而是设计一个刚好能解决当前问题、未来可以扩展的架构。
要么过度设计，为永远不会到来的未来做准备；要么设计不足，开发到一半就要推倒重来。这两种情况都会浪费大量时间。优秀的工程总监和普通工程师的区别不在能写出多复杂的代码，而在于能预见所有可能的失败模式。/plan-eng-review就是模拟这种思维方式，针对每一个设计决策追问："如果这个地方出问题了会怎么样？"
它最有价值的输出不是架构图，而是风险评估。它会告诉你哪些地方是故意做的简单设计，哪些地方预留了未来扩展的空间，哪些地方是潜在的风险点。
/design-html：从任何输入到像素级代码
它能把任何形式的设计输入转换成和原图高度一致的HTML代码，误差控制在像素级。
设计师给的设计稿和工程师写的代码永远有差距，来回沟通浪费了大量时间。据统计，前端开发中30%的时间花在了"对齐设计稿"上。大多数AI设计工具生成的是"看起来像"的代码，而不是"完全一样"的代码。/design-html的要求是像素级精确，每一个颜色、每一个字体、每一个间距都要和原图一致。
支持图片、线框图、手绘草图、文字描述、Figma链接等多种输入，生成的代码自带响应式，自动适配移动端和桌面端。
/review：只找问题不改代码的审查者
它只负责挑问题，绝对不修改代码，是角色边界最严格的Skill之一。
用同一个AI写完代码再审查，本质上是自己当自己的评委，必然会有注意力偏向，漏掉大量明显问题。/review严格切断创作上下文------它只读最终代码，看不到之前的创作过程和需求讨论，完全以第三方视角做中立审查。边界非常清晰：只指出问题、给出修改方向，绝对不动手改代码，避免角色混淆。
检查清单覆盖代码规范、逻辑漏洞、性能隐患、可维护性四个维度，是代码合入前的最后一道质量闸门。
/autoplan：GStack和Superpowers的无缝桥梁
自动把工程计划转换成符合Superpowers规范的任务列表，不需要任何手动转换。
之前需要手动将GStack的工程计划转换成Superpowers的任务格式，浪费时间且容易出错，通常需要30分钟到1小时，很容易遗漏重要细节。/autoplan理解两边的格式，会自动将大任务拆分成单个不超过4小时的小任务，为每个任务添加明确的完成标准，并自动标注对应的Skill。
Superpowers是底层任务执行层，负责单任务的代码落地；GStack是角色决策层，负责全流程的质量把控。/autoplan就是两者的衔接层。
/qa：疯狂的测试工程师
它会像真正的用户一样，疯狂地尝试破坏你的应用。
AI写的测试总是只测正常情况，不测边缘和异常。它们写的是刚好能通过的测试，不是能发现bug的测试。大多数测试工程师想的是"验证功能是否正常工作"，优秀的测试工程师想的是"怎么才能让这个功能崩溃"。/qa就是模拟这种破坏性思维。
它会自动读取git diff，识别哪些页面和路由受了本次修改的影响，然后针对性生成测试用例。测试完成后生成详细报告，包含失败用例的截图和复现步骤。社区反馈显示，/qa能发现80%以上的前端交互bug，效率远超人工黑盒测试。
/cso：首席安全官
它会用攻击者的视角审查你的代码，找出你和其他AI都发现不了的安全漏洞。
AI写的代码经常有严重的安全漏洞，而大多数开发者没有能力发现它们。据统计，AI生成代码中安全漏洞的数量是人类写的代码的2-3倍。安全审计的本质是对抗性思维------需要像攻击者一样思考才能发现漏洞。/cso内置了OWASP Top 10和STRIDE威胁模型，从攻击者的角度审查每一行代码。
核心检查项覆盖SQL注入、XSS、CSRF等常见漏洞，权限越界和访问控制问题，敏感数据泄露，依赖项安全风险，加密算法的正确使用。它不仅指出问题，还会给出修复建议和代码示例。
/land-and-deploy：一键生产部署
从代码合并到生产环境的完整自动化部署流程，不需要人工干预。
部署流程复杂容易出错，需要人工干预。据统计，30%的线上故障是部署过程中人为错误导致的。/land-and-deploy把所有部署步骤标准化、自动化了------从构建、测试、打包到部署、监控、回滚，每一步都有明确的检查点，任何一步失败都会自动回滚。
支持Vercel、Netlify、AWS、Fly.io、Railway等主流云平台。
/codex：代码库智能问答
用自然语言查询整个代码库，就像有一个熟悉所有代码的资深工程师随时在你身边。
大型代码库难以理解，找代码需要花费大量时间。据统计，开发者40%的时间花在了"理解现有代码"上。/codex基于GBrain的代码索引能力，当你提问时检索相关代码片段，然后用自然语言解释给你听。它不仅能理解代码的语法，还能理解设计意图和业务逻辑。
可以回答任何关于代码库的问题，找到特定功能的实现位置，解释代码的工作原理，梳理依赖关系，甚至提出改进建议。
五、设计哲学：为什么纯文本是最好的工程语言
GStack的所有逻辑都是纯Markdown写的，没有一行代码拦截，没有外部依赖。这不是技术限制，而是深思熟虑的选择。
透明优于黑盒
最好的工具是你可以完全理解和修改的工具。如果工具的逻辑用代码写的，只有程序员能理解和修改；如果用纯文本写的，任何人都可以。纯文本的Skill文件就像公司的规章制度------公开的、明确的、可讨论的。团队中每个人都能看到每个角色的职责和工作流程，有问题直接修改，不用等工具开发者更新。
约束优于自由
GStack的每个Skill都有严格的边界和流程限制。/review只能找bug不能修bug；/ship只负责发布不能讨论产品方向。这些约束不是为了限制AI，而是帮助它。大模型能力太强了，不给它明确边界它就会做很多无关的事。严格的角色边界模拟了真实团队中的专业分工，是质量保证的第一道防线。
决策前置优于执行优化
软件开发中最昂贵的错误不是代码写错了，而是做了错误的事。GStack把80%的精力放在开发前的决策阶段，通过多道审查门，确保在写第一行代码之前就已经想清楚了"要不要做"和"怎么做"。这和大多数AI工具的思路正好相反------大多数工具在优化写代码的速度，GStack在优化写正确代码的速度。
六、适用边界
GStack不是万能的，适用范围很明确。
适合的：从0到1的Web应用和SaaS产品开发；需要快速迭代验证的创业项目；一个人或小团队的全栈开发；产品驱动的业务系统开发。
不适合全流程替换的：纯底层系统、内核、驱动开发（需要极致的性能控制）；已有完整成熟工程体系的大型团队，可作为安全审计、文档生成等单点能力补充；一次性简单脚本或工具（流程overhead大于收益）；对性能有极致要求的系统（如高频交易、游戏引擎）。
只要你的项目需要和用户交互、需要做产品决策，GStack就是目前最好的选择。
GStack的创新不是代码生成，而是角色化认知隔离------从机制层面解决了单角色AI"自己审自己"的问题。三个底层支柱：纯Markdown声明式角色系统、持久化浏览器守护进程、GBrain项目级持久化内存。最常用的10个Skill覆盖了从产品到上线的全流程。纯文本的设计哲学让它比代码实现的框架更透明、更灵活、更可定制。