AI 写了一百万行代码后，我学到了什么
yyzyfish5: 我不会写代码。
过去两个月，我主要通过 AI Coding 做了一个叫 MarkOVO 的项目：把 PDF、Word、PPT 等多格式文件统一转换成 Markdown，支持 Web、API、CLI 和 MCP 四种使用方式。
Git 历史里累计新增了大约 101 万行内容。代码、测试和文档都由 AI 完成，我主要负责决定做什么，以及最后的结果能不能上线。
## TL;DR：我的几个关键认识
- AI 可以快速写出大量功能，但决定做什么、应该怎么做，比写出功能更重要。
- 哪怕是最强的 AI 模型，如果没有先设计好交互，最后做出来的还是一坨屎，给再多 skills 也没用。
- 巨量的真实测试集和人工检查，是保证最终效果的核心。测试覆盖率 90%，产品照样可能不能用。
- Markdown 很适合 AI 做计划、记忆和长程执行，但 HTML 才适合人把握项目。
- Human in the Loop 会是一个相对长期的状态。人可能会越来越少写代码，但仍然要为 AI 做出来的结果负责。
## 为什么做 MarkOVO
最开始只是因为我经常需要把文件交给 AI 处理。但之前 Cursor 经常打不开 PDF。所以我想先把文件统一转换成 Markdown，同时尽量保留表格、图片等原始文件等信息，感觉是有一定需求的，就开始干了。
文件只需要处理一次，后面无论交给哪里继续处理，都可以持续使用。这就是 MarkOVO 最开始的需求。
## AI 最大的问题，不是做不出来，而是什么都做
AI 不会拒绝需求。
你让它加一个状态，它就加一个状态；让它补一句提示，它就补一句提示；麻烦的是，它不仅什么都想做，还什么都想展示出来。
之前在 x 上看到这样的一段：你让 AI 做一盘炒面，它端上来一锅炖牛肉。
你告诉它：“不要炖牛肉，我要炒面。”它说 OK，给你一个文档：“炒面制作思路（没有炖牛肉版）”。
它不会真正删除那个错误的思路，而是把“为什么不做炖牛肉”也变成产品的一部分。
做 UI 时尤其明显——功能、状态、解释全部都放到页面上。每一项看起来都有信息，但当所有信息都被展示出来时，实际上就等于没有信息。
所以做 AI Coding，不能只是不断告诉 AI 增加什么，还要明确告诉它什么不应该出现，什么必须被删除，用户这一刻只能看到什么。如果信息层级和交互没有先设计清楚，再强的模型也只会高效率地做出一大坨。
## 测试覆盖率 90%，结果照样可能不能用
AI 很擅长在自己的边界里完成任务。
你让它做 A、B、C、D，它就测试 A、B、C、D，然后告诉你全部通过。但真实用户不会按照这个边界使用产品，真实的情况往往才是现实而复杂的。
在文件转换里，我们遇到过很多这种问题：
- 表格成功提取了，但行列关系乱了；
- 图片和文字都还在，但图片位置和对应内容对不上；
- 用户没有登录，系统却只提示 credits 不足，而不是告诉他先登录。
这些问题都无法在自动化测试中检查出来——AI 的自动化测试验证的是：系统有没有按照写下来的规则运行，然而它本身就预设了“完成边界”。
所以我们人工需要验证的是：这个东西到底符不符合真实用户的预期。
所以我现在认为，一个功能“完成”至少意味着：代码已经处理完，已经合并，已经成功部署，并且用真实文件人工检查过最终效果，这样才算完成一个部分的更新。
这也可能是未来 AI 开发里越来越重要的一个问题：到底什么时候才算 OK？
AI 不会主动停下来。只要继续给它时间，它永远可以再重构一次、再补一批测试、再增加一个抽象层、再做一轮优化。
写代码的成本越来越低以后，真正困难的反而是定义：做到什么程度就应该停止。
## Markdown 适合 AI，但不适合人掌控项目
Markdown 很适合 AI 工作。
需求可以写成计划文档，执行过程可以更新进度文档，遇到的问题可以写进记忆文档。AI 可以在任何时候继续使用这些文档、这个范式对 AI 很有效，但 MD 对人却并不友好。
在现在，一次长程任务可能连续执行五六个小时。AI 交给你审批的大量计划，里面充斥着各种信息、它创造的概念。在读文件的时候，很难理解它说的每一个 Gate、Layer 或 Package 到底是什么，这样的结果就是，在推进计划的时候只能扫一遍保证“看起来没啥问题”，就推进了。
随着项目发展，项目开始超出你的认知边界，这种“看起来没问题”，就变得越来越难以把握了。甚至说，AI 说“完成了”，可能只代表代码在本地写完了。它不一定已经合并，不一定已经部署，甚至可能部署失败了，而人可能迷失在这种持续推进的过程。
所以我现在开始构建和使用 HTML 控制台。通过这种更可视化的方式，把握我们下一步要做的这个计划中几个关键点是哪些，然后我需要判断的一些点是哪些，以及我们之前完成的项目，它是不是已经部署了等。Markdown 是 AI 的工作区，HTML 才应该是人的控制台。
## 人会越来越少写代码，但持续 in the loop
以我目前在一线互联网里看到的情况，说 90% 以上的代码由 AI 生成，可能是一个相对保守的说法。人更多是在做架构判断、理解改动和 review 结果。
而在 MarkOVO 里，因为我不会写代码，所以也不会做任何代码 review。我的判断只能往结果端走：最终结果能不能用、异常情况是否合理、部署以后是否真的生效。
理论上，除非我们能在项目开始前就把所有要点、边界和验收标准想得非常完整，再配合高度自动化的验收程序，才有可能把人工介入降到很低。但这件事本身的成本也非常高。更现实的方式，还是让人在执行过程中持续介入，在关键节点检查结果，尽量保证 AI 最终产出的东西真的没有问题。
这也是为什么我觉得 Human in the Loop 会长期存在。
人可能越来越少亲自写代码，但仍然要决定做什么、什么时候停止，以及最后这个结果能不能交给用户。
本质上，人仍然要为 AI 做出来的东西负责。
## 我还没有完全解决的问题
一个人通过 AI 管理几十万行代码，最难的不是继续增加功能，而是怎么保证项目没有脱离自己的控制。
AI 可以连续执行几个小时，可以不断创造新的概念和抽象，也可以在一个错误方向上越走越远；人在这个过程中不可能逐行 review，也不可能完整阅读它产生的所有文档。
我现在的做法，是限制任务边界、积累真实测试集、增加合并和部署检查，再通过 HTML 把项目状态重新展示给我做判断。但这里其实还有一个更根本的问题：当一个项目越来越多的部分已经超出我的认知边界，我无法理解它，也无法给 AI 足够正确的建议时，我要怎么继续驱动它往前走？
尤其是权限、安全这类我本身并不懂的模块，我怎么确认 AI 写出来的东西真的没有问题，而不是只是“测试通过了”或者“看起来能跑”？
这可能是 AI Coding 接下来很重要的一个问题：人怎么管理一个已经超过自己专业能力边界的项目。
对我自己来说，这可能也意味着另一件事——AI 可以降低写代码的门槛，但它并不会完全消除学习的必要。项目越往深处走，我可能还是需要补上足够的知识，至少让我知道哪些地方不能只相信 AI。
MarkOVO 目前还在持续开发优化，欢迎体验：
[https://markovo.net/](https://markovo.net/)
[https://markovo.net/pdf-to-markdown](https://markovo.net/pdf-to-markdown)
福利！发邮件到 support@markovo.com 领取一些免费的使用 credit 吧！
---
原文链接：[点击查看](https://www.v2ex.com/t/1236531)
过去两个月，我主要通过 AI Coding 做了一个叫 MarkOVO 的项目：把 PDF、Word、PPT 等多格式文件统一转换成 Markdown，支持 Web、API、CLI 和 MCP 四种使用方式。
Git 历史里累计新增了大约 101 万行内容。代码、测试和文档都由 AI 完成，我主要负责决定做什么，以及最后的结果能不能上线。
## TL;DR：我的几个关键认识
- AI 可以快速写出大量功能，但决定做什么、应该怎么做，比写出功能更重要。
- 哪怕是最强的 AI 模型，如果没有先设计好交互，最后做出来的还是一坨屎，给再多 skills 也没用。
- 巨量的真实测试集和人工检查，是保证最终效果的核心。测试覆盖率 90%，产品照样可能不能用。
- Markdown 很适合 AI 做计划、记忆和长程执行，但 HTML 才适合人把握项目。
- Human in the Loop 会是一个相对长期的状态。人可能会越来越少写代码，但仍然要为 AI 做出来的结果负责。
## 为什么做 MarkOVO
最开始只是因为我经常需要把文件交给 AI 处理。但之前 Cursor 经常打不开 PDF。所以我想先把文件统一转换成 Markdown，同时尽量保留表格、图片等原始文件等信息，感觉是有一定需求的，就开始干了。
文件只需要处理一次，后面无论交给哪里继续处理，都可以持续使用。这就是 MarkOVO 最开始的需求。
## AI 最大的问题，不是做不出来，而是什么都做
AI 不会拒绝需求。
你让它加一个状态，它就加一个状态；让它补一句提示，它就补一句提示；麻烦的是，它不仅什么都想做，还什么都想展示出来。
之前在 x 上看到这样的一段：你让 AI 做一盘炒面，它端上来一锅炖牛肉。
你告诉它：“不要炖牛肉，我要炒面。”它说 OK，给你一个文档：“炒面制作思路（没有炖牛肉版）”。
它不会真正删除那个错误的思路，而是把“为什么不做炖牛肉”也变成产品的一部分。
做 UI 时尤其明显——功能、状态、解释全部都放到页面上。每一项看起来都有信息，但当所有信息都被展示出来时，实际上就等于没有信息。
所以做 AI Coding，不能只是不断告诉 AI 增加什么，还要明确告诉它什么不应该出现，什么必须被删除，用户这一刻只能看到什么。如果信息层级和交互没有先设计清楚，再强的模型也只会高效率地做出一大坨。
## 测试覆盖率 90%，结果照样可能不能用
AI 很擅长在自己的边界里完成任务。
你让它做 A、B、C、D，它就测试 A、B、C、D，然后告诉你全部通过。但真实用户不会按照这个边界使用产品，真实的情况往往才是现实而复杂的。
在文件转换里，我们遇到过很多这种问题：
- 表格成功提取了，但行列关系乱了；
- 图片和文字都还在，但图片位置和对应内容对不上；
- 用户没有登录，系统却只提示 credits 不足，而不是告诉他先登录。
这些问题都无法在自动化测试中检查出来——AI 的自动化测试验证的是：系统有没有按照写下来的规则运行，然而它本身就预设了“完成边界”。
所以我们人工需要验证的是：这个东西到底符不符合真实用户的预期。
所以我现在认为，一个功能“完成”至少意味着：代码已经处理完，已经合并，已经成功部署，并且用真实文件人工检查过最终效果，这样才算完成一个部分的更新。
这也可能是未来 AI 开发里越来越重要的一个问题：到底什么时候才算 OK？
AI 不会主动停下来。只要继续给它时间，它永远可以再重构一次、再补一批测试、再增加一个抽象层、再做一轮优化。
写代码的成本越来越低以后，真正困难的反而是定义：做到什么程度就应该停止。
## Markdown 适合 AI，但不适合人掌控项目
Markdown 很适合 AI 工作。
需求可以写成计划文档，执行过程可以更新进度文档，遇到的问题可以写进记忆文档。AI 可以在任何时候继续使用这些文档、这个范式对 AI 很有效，但 MD 对人却并不友好。
在现在，一次长程任务可能连续执行五六个小时。AI 交给你审批的大量计划，里面充斥着各种信息、它创造的概念。在读文件的时候，很难理解它说的每一个 Gate、Layer 或 Package 到底是什么，这样的结果就是，在推进计划的时候只能扫一遍保证“看起来没啥问题”，就推进了。
随着项目发展，项目开始超出你的认知边界，这种“看起来没问题”，就变得越来越难以把握了。甚至说，AI 说“完成了”，可能只代表代码在本地写完了。它不一定已经合并，不一定已经部署，甚至可能部署失败了，而人可能迷失在这种持续推进的过程。
所以我现在开始构建和使用 HTML 控制台。通过这种更可视化的方式，把握我们下一步要做的这个计划中几个关键点是哪些，然后我需要判断的一些点是哪些，以及我们之前完成的项目，它是不是已经部署了等。Markdown 是 AI 的工作区，HTML 才应该是人的控制台。
## 人会越来越少写代码，但持续 in the loop
以我目前在一线互联网里看到的情况，说 90% 以上的代码由 AI 生成，可能是一个相对保守的说法。人更多是在做架构判断、理解改动和 review 结果。
而在 MarkOVO 里，因为我不会写代码，所以也不会做任何代码 review。我的判断只能往结果端走：最终结果能不能用、异常情况是否合理、部署以后是否真的生效。
理论上，除非我们能在项目开始前就把所有要点、边界和验收标准想得非常完整，再配合高度自动化的验收程序，才有可能把人工介入降到很低。但这件事本身的成本也非常高。更现实的方式，还是让人在执行过程中持续介入，在关键节点检查结果，尽量保证 AI 最终产出的东西真的没有问题。
这也是为什么我觉得 Human in the Loop 会长期存在。
人可能越来越少亲自写代码，但仍然要决定做什么、什么时候停止，以及最后这个结果能不能交给用户。
本质上，人仍然要为 AI 做出来的东西负责。
## 我还没有完全解决的问题
一个人通过 AI 管理几十万行代码，最难的不是继续增加功能，而是怎么保证项目没有脱离自己的控制。
AI 可以连续执行几个小时，可以不断创造新的概念和抽象，也可以在一个错误方向上越走越远；人在这个过程中不可能逐行 review，也不可能完整阅读它产生的所有文档。
我现在的做法，是限制任务边界、积累真实测试集、增加合并和部署检查，再通过 HTML 把项目状态重新展示给我做判断。但这里其实还有一个更根本的问题：当一个项目越来越多的部分已经超出我的认知边界，我无法理解它，也无法给 AI 足够正确的建议时，我要怎么继续驱动它往前走？
尤其是权限、安全这类我本身并不懂的模块，我怎么确认 AI 写出来的东西真的没有问题，而不是只是“测试通过了”或者“看起来能跑”？
这可能是 AI Coding 接下来很重要的一个问题：人怎么管理一个已经超过自己专业能力边界的项目。
对我自己来说，这可能也意味着另一件事——AI 可以降低写代码的门槛，但它并不会完全消除学习的必要。项目越往深处走，我可能还是需要补上足够的知识，至少让我知道哪些地方不能只相信 AI。
MarkOVO 目前还在持续开发优化，欢迎体验：
[https://markovo.net/](https://markovo.net/)
[https://markovo.net/pdf-to-markdown](https://markovo.net/pdf-to-markdown)
福利！发邮件到 support@markovo.com 领取一些免费的使用 credit 吧！
---
原文链接：[点击查看](https://www.v2ex.com/t/1236531)
· 0 个赞