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