Mario 的日常 AI 编程工作流
Mario 使用 Agent 的方式不是“把需求扔进去然后等结果”，而是一套很清晰的工程工作流：先分析，再实现；先验证，再提交；能自动化的杂事交给 Agent，关键判断仍由人负责。
他的一个典型流程从 GitHub issue 开始。因为现在很多 issue 可能是用户的 Agent 写出来的，里面的分析未必可靠，所以他不会直接相信 issue 里的判断。Pi 会先通过 GitHub CLI 拉取 issue，把 issue 自动标记为 in progress，分配给当前维护者，然后开始独立分析：复现问题、阅读相关代码、找出根因，并给出结构化结论。
这里有一个很重要的细节：他要求 Agent 忽略 issue 作者的分析，优先自己复现和验证。因为用户报告的问题可能是真的，但用户或用户的 Agent 对根因的判断经常是错的。真正值得信任的是可复现现象、代码事实和测试结果。
当 Agent 完成分析后，Mario 会先读分析，而不是马上让它改代码。如果他判断分析合理，就会选择下一步。对于非常确定、低风险的问题，可以直接让 Pi “wrap up”：实现、跑检查、更新 changelog、评论 issue、commit、push、关闭 issue。对于可能引入复杂度的小改动，他会先只让 Pi “implement”，不提交，等自己看完 diff 再决定。
这体现了他的一个核心原则：自动化流程不等于放弃审查。比如访谈里的例子是图片 token 估算漏算的问题。Agent 找到了两个需要修复的位置，也实现了修复。但 Mario 仍然会打开 diff，检查它有没有引入不必要的函数、重复代码或过度抽象。因为 Agent 很容易把一个三行修复包装成一个看起来更“工程化”、实际更复杂的方案。
等他确认代码结构可以接受，才会进入 wrap 阶段。这个阶段 Agent 会执行很多人不想手动做的事情：更新 changelog、写 GitHub 评论、提交 commit、添加 closes issue 信息、push 到远端。如果 rebase 或 merge conflict 发生，Agent 也会尝试处理，但复杂 Git 操作仍然需要人保持警觉。
这个工作流的价值不在于“AI 自动写完了所有代码”，而在于把人的注意力集中到真正有判断价值的地方。人不再把时间浪费在 GitHub UI、机械评论、重复命令和样板提交上，而是审查分析是否正确、实现是否过度、边界是否合理。
所以 Mario 的日常 AI 编程工作流可以总结为四步：
- 让 Agent 独立分析和复现问题。
- 人判断分析是否可信。
- Agent 实现最小改动。
- 人审查复杂度，再由 Agent 自动完成收尾工作。
这是一种很朴素但很有效的模式：Agent 提高吞吐，人控制方向。