第一次用 AI 用出了挫败感。

同感，过度设计，md ，我一个内部平台，各种安全性考量设计，机制复杂

@0x114514 #10 #11
过度设计也是一个可以拉扯的点啊。
你就和 AI 说，我想要简化设计，不要弄那么多方法，帮我看情况合并一下。

但是话又说回来了，改个功能跳转 N 行，又不需要你跳转，AI 改代码你还要帮他考虑跳转 N 行的问题吗。

vibe 之前先 grill me 做好粗略的设计，写通一遍能用的版本 commit 了，再跟 AI 一起 review/refactor 架构、命名、文档

你需要参考 matt pocock 的 skill 的方法论来做设计操作，尤其是 wayfinder 就是一个最好的例子。
你跟着他的流程做一遍自己脑子就有整个流程图和大概的模块的思路，和哪里需要削减了。
ai 做设计最忌讳就是一次性把所有模块一起设计完，这样既管理不到细节，也因为生成的文档量太大了整体也把握不好。

再用几年怕 for 循环都忘了😅

只会写点简单 crud🫠

头像真的很应景了

未来就是这样的开发方式，AI 会越来越强，根本没必要看代码，也不一定是程序员在开发了

模型 A 写代码出项目 wiki ，模型 B 根据项目 wiki 挑刺 A 写的代码，出具复核意见，让模型 A 驳斥 B 的复核意见，重复几次到模型 A,B 说的纯粹是鸡蛋里面挑骨头就算通过了，这个时候你对项目的构建，就了解的差不多了，你的作用就是模型 A 和 B 之间的小人，想办法让他们打起来，我司就是根据这套理论构建了一个自动化的流程，除了贵，没啥缺点

抓大放小，业务域、业务流程、状态机清楚就行，还有测试用例生成后先人过下

改旧代码确实有点慌，在屎山上雕花很恐怖

你不需要对方案满意。ai 的应该不是应该由你去承担。多想一想周末去哪里玩，预祝你周末快乐

其实我觉得 ai 时代更安全可靠的开发架构就应该是微服务架构，每个服务只负责一个业务，然后调度中心的网关稍微上点心写，这样子 ai 在每个微服务里拉屎也能把风险隔离开

我不会写 nuxt ，让 ai 给我写好了，就算让我看，我也看不懂啊

我时常看见 AI 写的一大坨代码恐慌，期望别再往这里再增加需求了，丢失了掌控感

让它跟你解释，与你 心智对齐。
让它补全文档，说明模块划分和 模块间组织关系。
让它提供方案，分析决策影响和技术债务

@ntdll 其实 AI 给的方案很好，就怕在实现过程中走偏了，或者是藏了看不见的坑。op 应该是不放心，怕真除了问题又不知道从哪下手改。

一样的兄弟，时常看不懂 AI 写的代码，特别是体积庞大的老系统，里面的业务逻辑弯弯绕绕，只能交给 AI 写了。

我一直主力用的 copilot ，乍换成 Codex 就有这种感觉。
看到 OP 的帖子也对比思考了下，
Codex 的工作流程缺少一种 可观察性，跳跃，等了几分钟等到一个结果，为什么改？不知道。
这确实很容易给人挫败感。

讨论了下，给 agents.md 加上这段， 看看效果，抛砖引玉，也给 OP 提供一点思路。

## 可观察工作流

- 开始前：说明正在检查什么，以及判断标准。
- 得出结论时：立即告诉我证据，不等全部做完。
- 修改前：列出准确文件、当前内容、准备改成什么，以及修改原因。
- 线上或多文件写入前：暂停一次，等我确认后再执行。
- 长操作期间：至少每 30 ～ 60 秒汇报当前阶段，避免无反馈等待。
- 遇到不确定情况：明确标注“已确认、推测、待验证”，不把推测当结论。
- 主动打开修改前后的 VS Code 对比。