《入职大厂两个月，我的 AI 开发心得》
作者: 黄同学h @huangtongxueh
入职大厂两个月，作者主要负责 Agent 开发与已有后端业务维护。借助合理的 AI 工具分工、个人 Harness 工程化搭建与严密的 Code Review 体系，实现了“需求做得又快又好，已经成为多个项目的主 O”。
背景：从沉重 Skill 到模型“做减法”
起因是和组里老板进行了几次 one-on-one。他对我目前使用 AI 工具、搭建个人 Harness，以及 AI Coding 的工作流很感兴趣。主要也是因为，我现在的需求做得又快又好，已经是一些项目的主 O 了。
因此，我也借这个机会，整理了一下自己的日常 AI 工作流。目前，我在组里主要做 Agent 开发，同时维护已有的后端业务。
之前，我在小红书里分享过相关的工作流。当时的背景是，GPT-5.4 和 Opus 4.6 已经能在获得准确上下文和合理约束的情况下，很好地完成任务。Harness Engineering 的兴起，也让大家意识到：可以通过增加约束，更好地驾驭强大的模型。
比如 Superpowers 这类 Skill，就提供了一套比较重的实现，主要围绕 Spec 和 TDD，帮助大家更容易地组织和推进任务。
像 Superpowers 这样的 Skill 包含大量约束模型下一步行动的 Workflow。哪怕从全局来看，某个步骤已经没有必要了（比如上下文已经足够可以直接写代码），模型仍然可能死板地沿着既定流程一步步磨蹭。随着新模型推理能力的大幅飞跃，原本被认为有用的约束，正在沦为模型的认知干扰噪声。
比如 OpenAI 在发布 Astra 时，还专门写了一篇博客，介绍如何清理不必要的 Skill 和系统提示词以改善体验。所以，这篇文章会结合我这几个月的实践，分享一些目前对我比较有效的做法，聊聊怎样更好地使用各类 Agent，提高日常开发效率。
一、我常用的 Skill 与 Prompt 快捷键
1. 我目前的工具分工矩阵
负责核心增量拆解、测试驱动编写与工程代码落地。执行力极强，但偶有过度设计的倾向，需要配合规则抑制。
复杂需求的前期方案规划。在 Astra 发布前主要使用 GPT-5.6 Sol Max 负责整体架构梳理。
低成本、高并发快速执行简单修改、脚本任务与轻量排障。
专门负责挑刺、寻找假设漏洞与逻辑死角；个人项目方案设计则采用网页端 GPT-6 Pro。
2. 我最常用的 7 款 Skill 资产
主要用于前期的方案对齐、多角度头脑风暴，快速发散与收敛思路。
核心用于需求澄清。通过连续追问把目标、约束和技术取舍问清楚，再沉淀到 ADR 或 CONTEXT.md 中，逼出潜意识盲区。
配合 grill 使用，将已经彻底澄清、边界分明的计划或具体 Issue 转化为高质量工程代码。
这个我极其高频使用！因为 GPT-5.6 Sol 很多时候会习惯性过度设计（加不必要的设计模式、状态机或中间层）。ponytail 强制删除非必要代码，极大减轻后续 Review 负担。
把当前会话的核心结论和待办整理成干净的 Markdown 文档，无缝从 Codex 切换交接给 Claude Code 或 pi agent。
在正式向团队提交 MR (Merge Request) 前执行，自动对齐团队静态代码规范和安全基线。
核心经验法则：日常工作中，任何一个自测或排障流程重复超过 3 次，就让 Codex 整理成 Skill，之后一键复用。
3. 5 大思维快捷键 Prompt：一句话指定认知动作
我现在已经很少手写几百行复杂的 Workflow Prompt 了。很多成熟的方法论，模型训练时已经读过海量论文和顶级设计。你不需要教它怎么从头思考，只需要给它“思维快捷键”，告诉它采用哪套方法论：
典型指令：不要基于“加 Redis 缓存”这个既定方案继续设计。从第一性原理分析这个接口为什么慢，以及最小必要的解决方案。
👉 效果：模型会从“怎么给 Redis 配参数”，切换为“瓶颈在 SQL、网络还是锁竞争？如果加个复合索引就能解决，为什么非要引入 Redis？”
典型指令：对这个方案做一次对抗性审查，优先寻找能推翻核心假设的反例。
👉 效果：针对分布式锁设计，它不再敷衍看超时时间，而是逼问：“重复请求真需要互斥吗？幂等能解决吗？锁服务挂了怎么办？锁过期但业务没跑完怎么办？”
典型指令：给这三个优化（索引、缓存、批量查询）设计消融实验，判断真正的收益来自哪里。
👉 效果：模型会拆分单变量对照组，往往发现“单加索引就把耗时从 800ms 降到了 120ms，剩下两个复杂设计只贡献了 20ms”，立即清理冗余代码。
典型指令：用奥卡姆剃刀重新审查这个设计，在满足需求的前提下，删除所有非必要机制。
👉 效果：把“Kafka + Redis + 状态机 + 定时补偿”重构回“单库事务 + 唯一索引”，大幅降低系统偶发性故障率。
典型指令：按高内聚、低耦合原则审查 OrderService 的职责边界，不要为了拆而拆。
👉 效果：激活模块化、信息隐藏与依赖反转的核心判断，理清哪些属于领域本身，哪些应走稳定接口隔离。
“从第一性原理重新分析，对当前方案做对抗性审查；核心机制必须通过消融实验验证；方案遵循奥卡姆剃刀，代码保持高内聚、低耦合。”
二、我的日常开发工作流（两阶段闭环）
阶段 ①：需求与方案对齐（控制对齐尺度，避免过重）
- 多源材料输入：将 PRD、会议纪要、聊天记录与用户真实反馈交给 Agent，结合团队 Wiki 和现有代码进行通读。真实场景下这些文档往往相互冲突、未及时更新。
- Grill 连续追问：让 Agent 扮演资深架构师连续质询，把会影响实现的目标、边界和取舍挖出来。当场回答一部分，不确定的找产品对齐。
- 对齐的黄金尺度：当剩下的问题已经不会显著改变实现方向和验收结果时，果断开始开发！绝不要求把所有微观细节提前规划死，否则需求对齐本身又会异化为过度设计的累赘。
- 沉淀 Spec / CONTEXT.md：记录本次迭代的目标、边界、决策和验收标准，后续并行 subagent 直接共享，无需重读万字长篇对话。
阶段 ②：可验收的小增量循环
三、怎么构建 Agent 友好的端到端测试 Harness
AI 已经非常擅长写单测了，动不动就给一个 Bugfix 堆上数百行测试。但很多时候，上线后依然会遇到意想不到的崩溃。核心症结在于：没有给 Agent 提供端到端的测试环境，让它在自测阶段就能触碰到真实的系统入口与数据库。
1. 端到端 Harness 的四大基础设施支柱
一键拉起沙盒/测试环境、Mock 测试数据，明确环境版本、权限与重置清理机制。
支持通过浏览器、API 或 CLI 命令行，完整走完真实的业务流转。
配置只读 DB MCP 验证落库状态，通过日志 Trace Skill 追查全链路调用与异常栈。
稳定操作做成脚本，入口和排障逻辑整理成 Skill，减少重复人工干预。
2. 经过一线检验的 4 个最佳实践做法
- 轻量浏览器自动化：需要浏览器操作时，推荐使用开源的
ego lite搭配pi agent + DeepSeek V4 Flash，执行极快且成本很低，能大幅缩减测试耗时。 - 操作统一封装成专用 CLI：把可复用的 Skill、MCP 和脚本集成到同一个内部测试 CLI 中，覆盖环境检测、数据准备、场景执行与清理。这既是 Agent 的测试工具，也是工程师本人的本地提效神器。
- 让工具服务于业务契约验收（不能看它返回什么就是什么）：
⚠️ 警惕验证陷阱：DB 用于确认状态，日志用于定位失败，但预期结果必须来自严格的业务契约！在复杂业务下，系统完全可能返回一个“看似合理但完全违背业务常识”的值。工具是帮我们获取证据，绝不能替人定义答案。 - 被测产品本身是 Agent 时的 Eval 评测：如果系统本身是智能体，除了流程跑通，还必须纳入输出质量评测（Agent Eval）。
四、怎么高效 Review AI 写的代码？
不论 AI 写得多么天花乱坠，业务需求的第一责任人永远是工程师自己。谁也不想半夜被报警电话叫起来 On-call，最后排查出来是 AI 悄悄写下的隐患。
不要只关注“测试用例通过了 100%”，而是先核对测试用例到底测了什么。很多时候 AI 为了通过测试，会故意写出迎合错误实现的断言。
将有限的审查精力锁定在：权限校验、核心状态迁移、高并发竞争、失败重试、数据一致性、数据库 Migration 与回滚。对于模式固定的单表 CRUD，现阶段我已经完全不花精力看了。
凡是看到新增的工厂类、泛型适配器或冗长状态机，立刻用奥卡姆剃刀质询：“有没有更简单的实现？是否在为假想的未来买单？”
将 Git 变更元数据与团队审查规范结合，构建专用的 Review Bot，在提交前过滤掉 80% 的低级低效缺陷。
五、总结与深度思考：AI 时代研发的核心护城河
目前我日常开发最明显的瓶颈，已经不是编码速度，而是人工 Review 的吞吐上限。
Agent 能在几个 worktree 里并行推进 3 个需求，但人类工程师理解业务、权衡边界、验收交付的心智带宽是有限的。如果只是一味让 AI 多写代码，最终只是堆积起一座无人敢碰的审查堰塞湖。
与此同时，工作流必须定期做减法。有些规则是过去为了给老模型的智力短板打补丁而设立的，新一代模型进化后，就该果断从 AGENTS.md 中删掉冗余约束，让模型发挥真实推理潜能。
AI 确实剥夺了一部分我们亲自踩坑的机会（从痛苦排障变成了听 AI 说一句“我错了，马上改”）。因此，我现在每天都会专门留出固定时间用来系统学习领域深水区知识与复盘。
🚀 给一线开发者的起步建议
不要试图一步到位搭建宏大的全自动框架。先挑一条你平时最常做的本地自测路径，试着让 Agent 独立跑通、保留证据，把有效步骤写成脚本沉淀下来，你的个人研发 Harness 就算正式启程了！