Ask HN：我停止了与AI过度依赖的斗争，并围绕它构建了一个工作流程
3 分•作者: dimonb19a•3 个月前
我是一名前端工程师，并且积极使用人工智能。我发现自己几乎从不手动编写代码，除非是需要微调一些样式。与AI时代之前相比，我感到懒惰和愚笨。即使是需要进行一些小改动，可能只需要2分钟就能完成，但我宁愿花这2分钟详细地向AI解释，并指出需要如何修改。因为我无需思考整个过程，只需表达想法和期望的解决方案，然后等待它完成并进行审查。
这在某种程度上是一种退化。但关键是，AI生成的代码质量非常出色。我的生产力和速度都得到了显著提升。
然而，有一个令人沮丧的问题。这种懒惰甚至开始影响审查过程。我不想花时间阅读和检查所有的改动，我宁愿让另一个AI来做。而且它确实有效！我大约95%的工作都使用Claude，然后切换到GPT来仔细审查。它们有不同的“个性”，所以你会得到不同的视角。我认为GPT像个书呆子，它能发现Claude会忽略的许多漏洞和不一致之处。所以我喜欢把它们俩关在一个房间里辩论。
我真正非常在意的是全面的文档。我花费大量时间与AI一起规划和头脑风暴，然后我会把一切都记录下来。所有关于架构的Markdown文件、组件使用指南、备忘录……所有这些都应该清晰可见，而不是深埋在代码中。每一次新的会话都从所有文档开始，其中详细解释了所有内容，并附带参考和示例，以防止AI敷衍了事或给出懒惰的答案。当我需要实现一个大的功能时，我会构建一个准备执行的计划，以便下一个具有新鲜上下文的AI能够阅读它——分析已完成的工作——弄清楚本次会话的任务——然后继续进行所有改动，并进行汇报。这可能意味着数十个聊天会话顺序地处理一个大项目；最后，我会运行一个工作流来审查所有实现，然后让GPT审计改动，只有当AI确认一切看起来都很好时，我才会亲自查看。届时，我可以指出哪些地方以及为什么需要重做，因为我不喜欢我们现在的方式。
在我的设置中，为AI准备的文档比代码更重要（每个级别的指令文件、按文件类型加载的规则文件、具有角色的子代理、围绕每次编辑的钩子）。最重要的部分包括：
* 一个“静默失败”的目录。36个编号的陷阱，它们可以编译通过但渲染错误。每个条目都是一个实际发生过的、已发布过的失败：原因、症状、修复方法。
* 一个“润色”规则。当你告诉AI“让它更好”时，它的本能是添加装饰性的东西。所以有一个明确的规则，即润色意味着“减法”，并列出了我在实际审查中拒绝过的模式。
* 当文档与代码不一致时，CI会失败。组件注册表会与源文件进行比对。因为有误导性的文档比没有文档更糟糕。
* 一个运行时验证器（WebMCP）。一个代理驱动一个真实的Chrome浏览器，点击页面，监控控制台，并在3个视口下截屏。
基本上，我停止了编写代码，开始设计编写代码的环境。每一个文件都存在，是因为AI曾经在某个地方失败过，而我把它记录下来，以防止再次发生。
对我来说最大的问题是动力。我记得那种卡住的感觉——几个小时都想不明白，寻找正确的解决方案，尝试，然后“操！终于搞定了！”的那种满足感：你做到了。我现在没有这种感觉了。即使在我完全不熟悉的领域，我也感到自信。感觉就像：“嗯，AI可以处理。”
我认为我的系统解决了质量问题，但加剧了懒惰/动力问题。我让懒惰变得安全。
所以有两个问题：
1. 你的AI设置是什么样的？我指的是实际的文件和规则，而不仅仅是你如何提示。
2. 有人真正解决了动力问题吗？
查看原文
I am a frontend engineer and actively use AI. I caught myself that i never write code manually, only if i have to tweak some styling. I feel lazy and dumb compared to pre-AI era. Even if i have to write some small changes in code that take like 2 minutes - it is easier to spend those 2 minutes explaining everything in details to AI and point out what and how it needs to change. Because i dont have to think about the process, i only explain the idea and desired solution - then wait until its done to review.<p>Thats some kind of degradation. But the thing is that the quality is amazing. My productivity and speed increased significantly.<p>But there is a frustrating thing. The laziness started affect even review process. I feel like i dont want to spend time to read and check all the changes - i will better ask another AI to do it. And it works! I use Claude for like 95% of work, then switch to GPT to review everything properly. They have different personalities so you have different points of view. I consider GPT as a nerd - it catches a lot of gaps and inconsistencies that Claude misses. So i like to close them both in one room to debate.<p>What i really do care a lot is a comprehensive documentation. I spend a huge amount of time for planning and brainstorming with AI, then i document everything properly. All those MD files about architecture, composition recipes, cheat sheet… All of it should lie on surface, not to be buried somewhere deep in code. Every cold session starts with all the docs where everything is explained properly with references and examples to prevent AI to skim or give lazy answers. When i need to implement some big feature i structure a proper ready-to-execute plan so every next agent with fresh context reads it - analyzes what was done - figures out what is the task for this session - and goes ahead with all the changes, then report. It can be dozens of chats working sequentially on some big thing; in the end i will run some workflow to review all the implementation, then ask GPT to audit changes, and i will look myself only when AI approves that everything looks great. Then i can tell what and why has to be redone because i dont like how we have it now.<p>In my setup the documentation for AI outweighs the code (instruction files on every level, rule files that load by file type, subagents with roles, hooks around every edit). The most weightful part:<p>- A catalog of silent failures. 36 numbered traps that compile fine but render broken. Every entry is a real failure that shipped at least once: cause, symptom, fix.<p>- A "polish" rule. When you tell AI "make it better", its reflex is to ADD decorative stuff. So there is a written rule that polish means subtraction, with a list of patterns i rejected in real reviews.<p>- CI that fails when docs drift from code. The component registry is checked against source files. Because docs that lie are worse than no docs.<p>- A runtime verifier (WebMCP). An agent drives a real Chrome browser, clicks through the page, watches the console, takes screenshots at 3 viewports.<p>Basically I stopped writing code and started engineering the environment that writes the code. Every file exists because AI failed at something once, and i wrote it down so it wont happen again.<p>The biggest problem for me is motivation. I remember that feeling how you got stuck - cant figure out something for hours, searching right solution, trying, and then FUCK YEAH FINALLY, and the satisfaction: YOU NAILED IT. I dont have it anymore. I feel confident even in things where i have no expertise at all. Thats like: meh AI can handle it.<p>I think my system solves the quality question, but increases the laziness/motivation problem. I made it safe to be lazy.<p>So two questions:<p>1. How does your AI setup look like? I mean real files and rules, not just how you prompt.<p>2. Has anyone actually solved the motivation part?