我不会写代码。
过去两个月，我主要通过 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/pdf-to-markdown
福利！发邮件到 [email protected] 领取一些免费的使用 credit 吧！
过去两个月，我主要通过 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/pdf-to-markdown
福利！发邮件到 [email protected] 领取一些免费的使用 credit 吧！
1
Select Language