当 IC Agent 会写、会跑、会改，工程师真正要保护的，不是岗位，而是失败、反馈和判断力训练。
小陈最近刚能独立负责一个小模块。
上周他花了两天定位一个很烦人的 bug：reset deassertion 之后，valid 信号在某个边界条件下多打一拍。
波形翻到眼睛发酸，log 看了好几遍，最后才发现是状态机转移条件里一个不起眼的判断。
这事不大，但对一个刚开始真正上手的工程师来说，很重要。
因为他不是只修了一行代码。
他顺着这个 bug，把 reset、backpressure、第一笔 transaction、valid/ready 的握手边界都重新摸了一遍。
被 reviewer 追问了几句以后，他才意识到：自己原来以为“跑过了”的东西，其实离“可以相信”还差一截。
然后这周，团队评审会上，大家看了一个 IC Agent demo。
Agent 读完 spec，抽出接口和状态机，生成 RTL，顺手补了 testbench。
仿真挂了一次，它读 log，给出 patch。
patch 过了简单 regression，dashboard 一片绿色。
最后还生成了一份总结：改了哪里，为什么改，目前哪些测试通过。
老板很兴奋。“这个效率可以啊。”
小陈也觉得厉害。但他心里一紧。
他真正想问的不是“这段代码能不能过当前 test”，而是：
它有没有查 reset 后第一笔 transaction？
有没有看 backpressure？
有没有想过这个 patch 对 CDC、低功耗状态切换、后面 signoff 的影响？
更要命的是，如果以后这些东西都被 Agent 预处理了，他还剩什么真正属于自己的护城河？
那些写错、跑挂、被打回、再一点点摸清边界的过程，还剩多少？
所以这篇不想再泛泛讨论“AI 会不会替代工程师”。
前几篇我们讲了行业价值、IC Agent 的护城河、本土 EDA 的窗口，以及验证证据链。
那些讨论主要是在看公司、工具和产业结构。
这篇换一个更贴近个人的问题：
当 IC Agent 真的开始写 RTL、跑工具、读 log、给 patch、整理报告，工程师还怎么长本事？
这里说的工程师，不只是写 RTL 的工程师。
验证里的 coverage hole，CDC/DFT/低功耗里的 warning 和 waiver，后端的 timing violation，CAD/flow 里的版本、配置和脚本边界，本质上都是训练材料。
岗位不同，材料不同，但问题很像：
你原本要亲手看 failure、追 warning、解释 report、判断证据够不够。
再说得具体一点：哪些能力只是入场券，哪些能力还能积累、迁移、定价？
我的判断可能有点刺耳：
IC Agent 最危险的地方，不是替你干活，而是把你本该亲手经历的失败、反馈和打回，一起提前处理掉。
这里说的“失败样本”，不是鼓励大家多犯错，也不是美化低效劳动。
它指的是一次判断被现实校准的过程：你原来怎么猜，现实怎么打脸，中间排除了哪些可能，最后靠什么证据改变判断。
现象、初判、排除路径、真因、修复方式、证据缺口，这些合在一起，才是工程师真正的训练样本。
先问一句：什么本事在 Agent 时代还值钱？
这个问题不先说清楚，后面很容易变成泛泛的职业建议。
一种答案是，工程师要更会写代码、更会写 RTL、更会写脚本。
这当然重要。
但如果只是比谁手写得快、样板写得熟、脚本拼得顺、report 整得快，Agent 会越来越强。
未来很多基础生成和整理动作都会被压缩，“我动作比别人快”很难变成长期护城河。
另一种答案是，工程师要更会用工具、更会写 prompt。
这也重要。
但会用工具和会用 Agent，大概率会变成入场券。就像今天不会用仿真器、不会看 waveform、不会跑 regression，很难说自己是合格工程师；未来不会用 Agent，也会差不多。
还有一种答案是，工程师要更懂芯片。
这句话当然对，但也容易说空。
懂芯片不是会背一堆名词，也不是知道更多缩写。
真正有价值的“懂”，是知道一个结果凭什么可信，知道一个 failure 可能从哪里来，知道一个 patch 会不会把风险挪到别处，知道哪些证据足够往下走，哪些证据只能先放在旁边。
工程师当然还有别的资产。
项目上下文、领域经验、组织信任、对公司内部 flow 的熟悉，都很重要。
下一篇我们会专门讲，怎么把这些经验沉淀成工程资产。
但对大多数工程师来说，最底层、最可迁移的一层，可以先落到一个更具体的词：
判断力。
我说的判断力，不是玄乎的“经验丰富”。它很具体：判断对错、风险、证据和边界。
Agent 会写，会跑，会改，会解释 report，会整理 log。
那你就更要知道：
它写出来的东西为什么对，
跑出来的结果覆盖了什么，
改出来的 patch 有没有副作用，
解释出来的 warning 能不能信，
什么时候可以往下走，
什么时候必须打回去。
这才是“长本事”的方向。
你不是要和 Agent 比谁更快完成动作。
你要借着 Agent 的速度，训练自己更快看见判断链。
这个判断落到行动上，第一步别急着收藏一百个 prompt。
先把自己的工作拆成两列。
第一列，是重复执行动作。
写样板 RTL，补 boilerplate testbench，拼脚本，跑固定 flow，翻普通 log，整理例行报告，把一堆 warning 归类，把一堆结果贴进周报。
这些事以前很占时间。Agent 进来以后，一定会被加速，很多甚至会被接走。
第二列，是工程判断训练。
spec 到底要求什么？
哪个 corner 不能漏？
这个 failure 是 design bug、test bug、constraint bug，还是环境问题？
这个 patch 是真修复，还是糊住当前 case？
这个 warning 能不能 waiver？
这个 ECO 有没有把风险挪到别处？
这次 flow failure，是工具配置问题，还是设计真的触到了边界？
说到底，第二列的问题都在追同一件事：
哪些证据足够支持下一步，哪些结论还不能信？
小陈那个 reset 后 valid 多打一拍的问题，如果换 Agent 来处理，它也许很快能定位到状态机那一行。
但这个 corner 为什么重要，类似疏漏以后会在哪里爆出来，这些判断不会随着 patch 通过就自动长出来。
甚至相反，如果你只接受 Agent 的最终答案，你会省下很多时间，也会错过很多训练。
左列可以交给 Agent，右列不能外包，只能借 Agent 提高训练密度。
会用 Agent 只是入场券，会审 Agent 的判断链才开始有价值。
过去一个 IC 工程师怎么长本事？
靠的不是几篇教程，也不是几场培训。
更多时候，是一串很笨、很慢、很疼的过程。
spec 看错一次。
RTL 写挂一次。
test 没覆盖到 corner。
仿真跑红。
waveform 看半天。
review 被打回来。
修完以后才知道，原来某个 warning 不能随便 waiver，原来某个 coverage hole 不是数字不好看，而是真的藏着风险。
这些东西很烦。但它们是训练样本。
更具体地说，失败样本常常就是那些让你看见自己判断缺口的瞬间：
你本来以为是 A，后来发现是 B；
你以为证据够了，后来发现还差一个场景；
你以为只是小 warning，后来才知道这类 warning 在某些项目里出过大事。
工程师的判断力，不是从正确答案里长出来的。
它是从失败、打回和复盘里长出来的。
这也是为什么我对“Agent 帮新人省掉低阶工作”这句话有点警惕。
低阶工作当然可以省。
没人怀念手工搬砖式劳动。麻烦在于，很多所谓低阶工作里，藏着新人最早接触工程现实的入口。
第一次自己把 test 写挂，
第一次盯着 waveform 找到状态机多跳了一步，
第一次发现 coverage hole 不是 KPI 小瑕疵，
第一次把 warning 追到真实风险，
第一次被 reviewer 问到哑口无言，
第一次意识到“pass 了”不等于“可以信了”，
这些都不是无意义消耗。
它们是工程判断力的反作用力。
Agent 如果只是帮你省掉重复动作，那很好。但如果它把这些反作用力也一起吃掉，年轻工程师就可能只看到干净结果，看不到脏过程。
长远看，这件事比少写几段 RTL、少看几份 report 更麻烦。
就拿一个再普通不过的 FIFO 来说。
Agent 读了失败 log 和波形，三分钟给出结论：full flag 更新慢了一拍。
它顺手给了一个 patch，当前 directed test 过了，dashboard 变绿。
这时候最诱人的选择是什么？
接受，合入，继续往前跑。
两周后，另一个场景又挂了。
这次是 simultaneous read/write 加 backpressure。
之前那个 patch 把当前 test 糊住了，但在另一个边界上引入了新问题。
再往下追，真正的 root cause 不是 full flag 本身，而是设计里没有清楚定义“满状态下读写同时发生”的优先级。
你看，这里面有两个完全不同的学习结果。
如果工程师只看 Agent 的最终 patch，他学到的是：“Agent 修好了。”
如果他追问 Agent 为什么定位到 full flag，排除了哪些可能，patch 覆盖了哪些边界，rerun 了哪些 case，为什么 simultaneous read/write 没被覆盖，他学到的才是工程判断。
所以 Agent 给了 patch 以后，至少追五个问题：
root cause 是什么？
排除了哪些可能？
patch 覆盖了哪些边界？
rerun 了哪些 case？
有没有把风险挪到别处？
这就是 debug 的价值。
类似的事也会发生在别的环节。
Agent 可以把一批 warning 解释得很顺，但工程师要知道哪些只是结构噪声，哪些可能对应真实风险。
Agent 可以给出 timing ECO 候选，但后端工程师要看它有没有把风险挪到 hold、拥塞或者功耗。
Agent 可以总结 regression failure，但验证工程师要分清这是 design bug、testbench bug、constraint bug，还是环境配置问题。
Debug 不是脏活，debug 是系统和现实对账的地方。
真实工程从来不是 spec 说什么，代码就自然长成什么。
中间有理解偏差，有约束漏项，有 testbench 假设，有工具配置，有历史代码，有项目节奏，还有很多“大家以为说清楚了，其实没有说清楚”的地方。
debug 正是在这些地方，把漂亮假设拉回现实。
可以让 Agent 加速 debug。
但不要让 Agent 替你吃掉所有 debug。
否则你得到的是一个更快的答案，却少了一次判断力训练。
那怎么办？
答案当然不是拒绝 Agent，也不是假装 AI 不懂芯片，然后继续用老办法慢慢熬。
更现实的做法，是把 Agent 当成加速器，同时有意识地保护自己的训练样本。
我建议从五件小事开始。
第一，建一个失败样本账本
别被“账本”这个词吓到，不需要搞成漂亮文档，也不需要写成项目复盘报告。每周记录一个 failure 就够了。
这个 failure 不一定是 RTL bug。
它可以是一次 regression failure，一个 coverage hole，一个 CDC warning，一个 timing violation，一次 flow failure，或者一个后来被证明不该签的 waiver。
格式很简单：
现象是什么？
我最初猜的原因是什么？
真正原因是什么？
中间排除了哪些方向？
最后怎么修？
rerun 了哪些 case？
还有什么证据其实不够？
重点不是记录得多完整，而是别让 failure 只在项目群里吵一轮，然后随着 patch 合入一起消失。
很多训练样本就是这么没的。
第二，每次用 Agent，都追问判断链
不要只问“怎么修”，要固定追三句：
你为什么这样判断？
你排除了哪些可能？
需要什么证据才能相信这个结论？
这三句有点啰嗦，但很管用。
因为它会逼你从“拿答案”切换到“看判断”。
如果 Agent 答不上来，或者答得很虚，当前 patch 即使跑过了，也别急着把它当成自己的经验。
第三，把一次 review 打回，改成下一次的 checklist
很多人被 review 打回以后，只想赶紧改完。这很正常，谁也不喜欢被指出问题。
但真正值钱的地方不是“这一行怎么改”，而是 reviewer 到底不放心什么。
他担心的是 reset 行为，还是协议语义？
是边界条件，还是时序假设？
是代码风格，还是证据不够？
是这个 waiver 太随意，还是这个 ECO 副作用没看？
是当前实现不好，还是这类写法以后很难验证、难 signoff？
把这些东西记下来。
下一次写类似模块之前，提前扫一遍。这就不只是挨了一次批评，而是多了一张自己的检查表。
第四，每周找一个 green check 追根
通过了当然是好事。但 green check 不是结论，只是下一轮追问的入口。
找一个已经通过的 case，问它几个问题：
它到底覆盖了什么？
没覆盖什么？
环境是什么？
版本是什么？
seed 是不是固定的？
有没有 rerun？
有没有可能只是当前 directed test 太窄？
这样做不是为了怀疑一切。
芯片工程里如果事事都不信，项目也别做了。
真正要训练的是另一种能力：分清“通过了”和“可以相信了”之间的距离。
第五，主动靠近 signoff 讨论
新人一开始当然做不了最终判断。但这不妨碍你去观察别人怎么判断。
一个资深工程师为什么看到某个 warning 会皱眉？
为什么某个 coverage hole 可以接受，另一个必须追到底？
为什么某个 waiver 可以签，另一个必须升级？
为什么某个 ECO 虽然局部漂亮，但他担心会把风险挪到 hold、功耗或者拥塞？
这些判断，不会自动写在教程里。
你要靠近它。
最简单的办法，是每周挑一个你没完全看懂的 waiver、coverage hole、warning 或者 timing violation，去问资深工程师三个问题：
你为什么放心？
你还担心什么？
如果这里判断错了，后果会在哪里爆出来？
单纯多写几段代码，当然有用。
但如果你一直看不到别人凭什么敢往下走，你的工程直觉会长得很慢。
以后成长最快的人，不一定是做最多低阶任务的人，而是最早开始记录失败、复盘判断、靠近证据和 signoff 的人。
这件事不能只交给年轻工程师自己解决。
如果团队只把 Agent 当效率工具，很容易无意中切断年轻工程师的成长路径。
以前新人可以通过做小任务、犯小错、被 review 来长大。
以后如果所有小任务都被 Agent 预处理，新人可能只看到干净结果，看不到脏过程。
更现实的问题是 KPI。
如果团队只看“省了多少人天”，所有人都会倾向于让 Agent 尽快吐出干净结果。
培养新人、沉淀 failure taxonomy、复盘判断链，都会变成“不紧急”的事。
KPI 不改，方法论很容易变成口号。
团队负责人至少可以做几件事。
第一，review 不只看代码，也看 Agent 的判断链。
第二，不要只让新人看 Agent 输出，也要让他看 Agent 的失败和修复路径。
第三，每个项目留一点 failure taxonomy 和 debug playbook。
说白了，就是把失败分类，把常见定位路径写下来，不要让所有经验都散在项目群和个人脑子里。
还可以安排一点“旁听 signoff 判断”的机会。
不是让新人拍板，而是让他看到：
一个 waiver 为什么可以接受，
一个 coverage hole 为什么必须追到底，
一个 ECO 为什么虽然局部漂亮但还不能放心。
复盘的时候，也别只问这次省了多少人天。
还要问：
这次留下了什么 failure 样本？
有没有新的 checklist？
有没有新的 guard？
有没有一个以后 Agent 或新人都能调用的判断规则？
Agent 时代的培养，不是让新人少犯错。
而是让新人更高密度地看见错误是怎么被识别、解释和关闭的。
Agentic EDA 不会把人从工程系统里拿掉。
至少在相当长时间里，不会。
它更可能改变人的位置。
过去很多时候，人要亲手做完每一步：写代码、跑工具、看 log、定位问题、修复、回归、整理报告。
以后，Agent 会接走其中越来越多动作。
但人不能只剩下点确认键。
人的位置会从“亲手做完每一步”，慢慢移到另一组动作上：追问判断链，审查证据，保护训练样本，复盘失败，并在关键节点承担最后判断。
这篇只讲一件事：
别让 Agent 偷走你长本事的失败样本。
失败样本保护住以后，下一步才是把这些失败样本、review 意见、debug 路径和 signoff 判断，沉淀成 Agent 可调用的工程资产。
那是下一篇要讲的事。
最后留一个问题：
你现在最想让团队沉淀的 failure 样本是哪一类：coverage hole、warning、timing violation、flow failure，还是一次被 review 打回的真实原因？
