今天只带走一个问题：一条工程经验，怎样才算变成了 Agent 能执行、工具能检查的知识？
论文卡片
- 原题： Academia x Industry: The Role of Fundamentals for Silicon in an AI Native Era
- 作者： Vincent T. Lee、Armin Alaghi、Carole-Jean Wu、Sai Zhang、Brandon Reagen、Thierry Tambe、Jean Boufarhat、Matheus Trevisan Moreira。
- 机构： Meta、纽约大学、斯坦福大学。
- 版本： 2026-09-08，arXiv v1；20 页；官方分类 cs.AR（硬件架构）。
- 定位： AI for Silicon、EDA、Agent 工作流与工程教育的交叉；观点与路线展望型论文。
- 阅读入口： alphaXiv · arXiv · 免费全文 · PDF
简短导读
作者主张：芯片设计自动化加深之后，基础知识仍决定工程师能否表达设计意图、组织工作与验证结果。只存在于专家脑中的经验，需要被写成明确的规格、约束和验收标准。已有的形式化验证等工具，可以为 Agent 提供可靠反馈；昂贵的 EDA 调用则需要纳入工作流成本。见原文 §2.2、§3.4、§5。
证据边界： 这篇适合建立问题地图。关于角色变化、工具生态与培训方式的许多判断属于作者展望，不能当作已经验证的生产力提升结论。
怎样读
先读 §2.2 隐性知识流失，找一条可以写下来的领域经验；再读 §3.4 正确性反馈，思考用什么检查它；最后读 §5.3 Agent 工作流设计，考虑如何接入任务流程。第一遍不必通读。
迁移到编译器工作：一个小例子
以下是导读者设计的练习，不是论文实验或复现结果。
假设给 Agent 一个任务：优化一个向量加法 kernel。只写“结果正确、尽量快”还不足以验收。可以先写一张任务卡：
| 项目 | 需要说明什么 |
|---|---|
| 输入范围 | dtype、长度、stride、设备，以及是否允许输入输出别名 |
| 正确性 | 使用哪个独立参考实现；浮点误差界限；哪些边界输入必须覆盖 |
| 性能 | 固定设备和软件版本，先预热，再重复测量；正确性通过后比较耗时 |
| 修改范围 | Agent 可改 kernel；验收标准和参考实现由独立流程维护 |
| 失败处理 | 返回最小失败输入、日志与修改记录；超过尝试预算后停止 |
例如长度不能被 block size 整除时，尾部元素是否正确处理？这条要求可以落成边界用例。测试通过只支持这些已测范围内的结论；要声称所有合法输入都正确，需要更强的证明与明确前提。
三个思考问题
1. 你脑中哪条经验，还没有进入规格或测试？
选最近一次 compiler / kernel bug，写成“在什么条件下，必须满足什么性质”。你会把它放进文档、断言还是回归测试？为什么？
展开参考思路
不要只写“注意边界”。试着明确触发条件、错误表现和检查方法。例如：“长度不是 block size 的整数倍时，只允许访问有效元素。”文档解释原因，测试检查实例，二者可以互补。
2. Agent 的修改通过了测试，什么情况下仍然不能接受？
列出一个测试没覆盖的失败模式，再说明你会增加什么独立证据。
展开参考思路
候选包括未覆盖的 dtype / stride、错误的误差阈值、被修改的参考实现，以及只在某个 shape 上成立的优化。先找“验收条件漏掉了什么”，再决定补测试、检查约束还是引入证明；换一个模型说“看起来正确”并不能自动补齐这些证据。
3. 怎样检验“结构化经验确实帮助了 Agent”？
给同一个小任务设计两组条件：A 只有需求，B 额外提供规格与检查入口。除了成功率，还应该记录什么？
展开参考思路
固定模型、工具版本与尝试预算，使用多个独立任务或重复运行。记录正确率、总耗时、工具调用成本和人工返工时间，并使用未暴露给 Agent 的验收用例。B 即使更可靠，也可能付出更多成本；小样本结果只能作为线索。
今日最小行动
用十分钟完成第一个问题，产出一条“条件—性质—检查方法”。暂时不搭大平台，让这条知识先能被另一个人或 Agent 准确使用。