零人类代码-我从强迫人工智能连续-27-天构建-并修复-自己的代码中学到了什么

零人类代码：我从强迫人工智能连续 27 天构建（并修复）自己的代码中学到了什么

原文：towardsdatascience.com/zero-human-code-what-i-learned-from-forcing-ai-to-build-and-fix-its-own-code-for-27-straight-days/

27 天，1,700+次提交，99.9%的人工智能生成代码

围绕人工智能开发工具的叙述越来越脱离现实。YouTube 上充斥着使用人工智能助手在几小时内构建复杂应用程序的声明。真相是什么？

我在 27 天内在一个严格的约束下构建了ObjectiveScope：人工智能工具将处理所有的编码、调试和实现，而我则纯粹作为协调者。这不仅仅是一个产品的构建——这是一次对代理人工智能开发真正能力的严格实验。

一个笨拙的人工智能实习生和一位沮丧的产品经理走进了一家酒吧……（图片由作者提供）

实验设计

两个并行目标推动了这个项目：

1. 将周末原型转变为全服务产品

2. 通过维持严格的“不直接修改代码”政策来测试 AI 驱动开发的实际极限

这种自我强加的限制至关重要：与典型的 AI 辅助开发不同，开发者可以自由修改代码，而我只会提供指令和方向。人工智能工具必须处理其他所有事情——从编写初始功能到调试它们生成的错误。这意味着即使是手动只需几秒钟就能完成的简单修复，也需要仔细的提示和耐心来引导人工智能找到解决方案。

规则

• 不直接修改代码（除了关键的模型名称修正——大约 0.1%的提交）

• 所有错误都必须由人工智能工具本身修复

• 所有功能实现都必须完全通过人工智能完成

• 我的角色仅限于提供指令、背景和指导

这种方法要么验证，要么挑战围绕代理人工智能开发工具日益增长的炒作。

开发现实

让我们抛开营销炒作。仅使用纯人工智能助手进行构建是可能的，但伴随着在技术圈和营销术语中讨论不足的重大限制。

不直接修改代码的自我限制将传统开发中可能微不足道的问题转变为人工智能指导和指导的复杂练习。

核心挑战

恶化的上下文管理

• 随着应用程序复杂性的增加，人工智能工具越来越难以跟踪更广泛的系统上下文

• 功能可能会因不必要的重创或看似无关的变化而损坏

• 人工智能在代码库中难以保持一致的架构模式

• 每个新功能都需要越来越详细的提示，以防止系统退化

• 需要引导 AI 理解和维护其自身的代码，这增加了显著的复杂性

技术限制

• 与过时知识的常规战斗（例如，持续尝试使用已弃用的第三方库版本）

• 模型名称的持续问题（AI 在调试会话中将其识别为代码中的“bug”时，不断将“gpt-4o”或“o3-mini”更改为“gpt-4”）。我直接干预的 0.1%都是为了纠正模型引用，以避免浪费时间和金钱

• 与现代框架功能的集成挑战变成了耐心指导的练习，而不是快速修复

• 代码和调试质量在提示之间有所不同。有时我只是回滚，并以更佳的结果再次给出相同的提示。

自我调试约束

• 对于人类来说可能只需 5 分钟就能解决的问题，却变成了引导 AI 数小时的细致工作

• AI 在尝试修复现有问题时，经常引入新的问题（甚至新的功能）

• 成功需要极其精确的提示和持续的警惕

• 每个错误修复都需要在整个系统中得到验证，以确保没有引入新的问题

• 更多的时候，AI 对其实际实施的内容撒谎！

总是验证生成的代码！（图片由作者提供）

工具特定见解

可爱

• 在初始功能生成方面表现出色，但在维护方面遇到困难

• 随着项目复杂性的增加，性能显著下降

• 由于响应时间增加和工具本身的错误，最终三天不得不放弃

• 在 UI 生成方面表现强劲，但在维护系统一致性方面较弱

光标 作曲家

• 更可靠地进行增量更改和错误修复

• 更擅长在单个文件内保持上下文

• 在处理跨组件依赖方面遇到困难

• 需要更具体的提示，但产生了更一致的结果

• 更擅长调试和控制

抽象概念的困难

我使用这些代理编码工具的经验是，虽然它们可能在具体任务和明确指令方面表现出色，但它们通常难以处理抽象概念，如设计原则、用户体验和代码可维护性。这种限制阻碍了它们生成不仅功能性强，而且优雅、高效且符合最佳实践的代码。这可能导致难以阅读、维护或扩展的代码，从长远来看可能会产生更多的工作。

意外收获

该实验产生了关于 AI 驱动开发的几个意外但宝贵的见解：

提示策略的演变

其中最有价值的成果是开发了一套有效的调试提示。通过试错，我发现了一系列指导 AI 工具通过复杂调试场景的模式。这些提示现在成为其他 AI 开发项目的可重复使用的工具包，展示了即使是严格的限制也能产生可转移的知识。

架构锁定

也许是最大的发现是，在纯 AI 开发中，早期架构决策几乎成为不可更改的。与传统的开发不同，在开发后期重构是一种标准实践，而在开发后期改变应用程序的架构几乎是不可能的。出现了两个关键问题：

文件复杂性增加

• 随着时间的推移而变大的文件，修改起来越来越有风险，因为重构文件通常需要数小时的迭代才能使事物恢复正常工作。

• AI 工具难以在大量文件中维持上下文

• 尝试重构往往导致功能损坏，甚至出现我未请求的新功能

• 在重构过程中修复 AI 引入的 bug 的成本往往超过潜在的好处

架构刚性

• 初始的架构决策对整个开发过程产生了不成比例的影响，尤其是在将不同的 AI 工具组合在一起处理同一代码库时

• AI 无法理解整个系统的影响，使得大规模变更变得危险

• 在传统开发中可能是常规重构的操作，现在变成了高风险且耗时的操作

这与典型的 AI 辅助开发有根本性的不同，在 AI 辅助开发中，开发者可以自由地重构和重构代码。纯 AI 开发的限制揭示了当前工具虽然初始开发强大，但难以应对软件架构的演变性质。

AI 开发的关键经验

早期决策至关重要

• 在纯 AI 开发中，初始的架构选择几乎成为永久性的

• 在传统开发中可能是常规重构的改变变成了高风险操作

• 成功需要比典型开发更多的前期架构规划

环境因素至关重要

• AI 工具在独立任务上表现出色，但难以应对系统级的影响

• 成功需要保持清晰的架构愿景，而当前的 AI 工具似乎无法提供

• 随着复杂性的增加，文档和上下文管理变得至关重要

时间投资现实

声称数小时内构建复杂应用程序的说法具有误导性。这个过程需要投入大量时间，包括：

• 精确的提示工程

• 审查和指导 AI 生成的变更

• 管理系统级的一致性

• 调试 AI 引入的问题

工具选择很重要

• 不同的工具在不同的开发阶段表现出色

• 成功需要理解每个工具的优势和局限性

• 准备好根据项目需求的变化切换或甚至组合工具

规模改变一切

• 人工智能工具在初始开发方面表现出色，但在处理日益增长的复杂性方面存在困难

• 系统级的变化随着时间的推移变得越来越困难

• 传统的重构模式不适合仅使用人工智能的开发

人的因素

• 人工智能系统的角色从编写代码转变为协调人工智能系统

• 战略思维和架构监督变得更加重要

• 成功取决于保持人工智能工具经常忽视的更大图景

• 当挫折积累时，鼓励进行压力管理和深呼吸

人工智能指令的艺术

或许这个实验中最实用的见解可以总结为一条建议：像对待一个真正笨拙的实习生一样进行提示工程。这不仅仅是有趣的——这是与当前人工智能系统合作的一个基本真理：

• 具体到痛苦的程度：你留下的含糊之处越多，人工智能做出错误假设和“搞砸”的空间就越大

• 无上下文假设：就像第一天实习的实习生一样，人工智能需要明确地指出所有内容

• 永远不要依赖假设：如果你没有指定，人工智能将做出自己的（通常是错误的）决定

• 检查一切：信任但验证——每个输出都需要审查

这种心态的转变对于成功至关重要。虽然人工智能工具可以生成令人印象深刻的代码，但它们缺乏即使是初级开发者也拥有的常识和情境理解。理解这种局限性将挫折转化为有效的策略。

当挫折占据主导地位时。一个不正确的提示示例 😅（图片由作者提供）

结果：一个功能齐全的目标实现平台

虽然开发过程揭示了关于人工智能工具的关键见解，但最终结果不言而喻：ObjectiveScope 成为一个复杂的平台，改变了自由职业者和小型团队管理战略规划和执行的方式。

ObjectiveScope 改变了创始人团队管理战略和执行的方式。在其核心，人工智能驱动的分析消除了将复杂的战略文件转化为可执行计划的困难——通常需要数小时的工作现在变成了 5 分钟的自动化过程。该平台不仅跟踪 OKR，还积极帮助您创建和管理它们，确保您的目标和关键结果实际上与您的战略愿景保持一致，同时自动保持一切更新。

ObjectiveScope 策略分析部分的截图（图片由作者提供）

对于创始人每天面临的混乱，智能优先级管理系统将压倒性的任务列表转化为清晰、战略一致的行动计划。不再有周日晚上的规划会议或对是否在正确的事情上工作的持续怀疑。该平台验证您的日常工作确实推动了您的战略目标。

团队协作功能解决了保持每个人一致性的常见挑战，无需无休止的会议。实时更新和基于角色的工作空间意味着每个人都知道自己的优先事项以及它们如何与整体画面相连接。

现实世界的影响

ObjectiveScope 解决了我在向初创公司提供建议、管理自己的企业或与其他创始人交谈时反复遇到的重大挑战。

我在规划上花费的时间减少了 80%，消除了杀死生产力的不断上下文切换，即使在最繁忙的运营期间也能保持战略清晰。这关乎将战略管理从负担沉重的开销转变为轻松的日常节奏，让你和你的团队能够专注于最重要的事情。

我将扩展 ObjectiveScope 以解决创始人团队面临的其他关键挑战。管道中的一些想法包括：

• 一个具有代理功能的聊天助手将提供实时战略指导，消除孤立决策的不确定性。

• 智能个性化将学习你的模式和偏好，确保推荐实际上符合你的工作风格和商业环境。

• 与 Notion、Slack 和日历工具的深度集成将结束在应用程序之间不断切换上下文，从而碎片化战略焦点。

• 预测分析将分析你的绩效模式，在它们影响目标之前标记潜在问题，并在需要时建议资源调整。

• 最后，灵活的规划方法——无论是按需还是预定——将确保你无论是在遵循稳定计划还是应对快速市场变化时，都能保持战略清晰。

每项增强都旨在将一个常见的痛点转化为自动化、智能的解决方案。

展望未来：实验之外的进化

初始的 AI 驱动开发阶段只是开始。向前看，我将采取更亲力亲为的方法来构建新的能力，这些能力将受到从这次实验中获得见解的启发。我当然不能冒险让 AI 在产品阶段完全自由地编写代码。

这种进化反映了实验第一阶段的关键学习：虽然 AI 可以独立构建复杂的应用程序，但通往产品卓越的道路需要结合 AI 能力、人类洞察力和直接开发专业知识。至少目前是这样的。

编码中“长期思考”的出现

通过 AI 开发中的推理模型转向“长期思考”标志着我们在未来构建软件方式的重大进化。这种新兴方法强调深思熟虑的推理和规划——本质上是以快速响应换取更好的工程解决方案。对于复杂软件开发来说，这不仅仅是一个渐进的改进；这是生产级代码的基本要求。

这种能力转变也在重新定义开发者的角色，但并非如许多人所预测的那样。AI 并非取代开发者，而是将他们的位置从代码实现者提升到系统架构师和战略问题解决者。真正的价值在于开发者专注于 AI 尚不能很好地处理的任务：经过实战考验的系统设计、架构决策和创造性问题解决。这不仅仅是自动化取代人工工作——这是自动化增强人类能力。

下一步：AI 能否运行整个业务运营？

我正在验证 ObjectiveScope——一个由 AI 构建的工具——是否可以完全由 AI 操作。下一阶段将超越 AI 开发，测试 AI 操作的边界。

利用 ObjectiveScope 自身的战略规划能力，结合各种 AI 代理和工具，我将尝试在没有人工干预的情况下运行所有业务运营——包括市场营销、战略规划、客户支持和优先级排序。

这是一个元实验，其中 AI 使用由 AI 构建的工具来运行 AI 开发的服务…

请继续关注更多消息！