yyzyfish5

我不会写代码。
过去两个月，我通过 AI Coding 做了一个叫 MarkOVO 的项目：把 PDF 、Word 、PPT 等多格式文件统一转换成 Markdown ，支持 Web 、API 、CLI 和 MCP 四种使用方式。
Git 历史里累计新增了大约 101 万行内容。代码、测试和文档都由 AI 完成。

TL;DR：
我的几个关键认识：
AI 可以快速写出大量功能，但决定做什么、应该怎么做，比写出功能更重要。
哪怕是最强的 AI 模型，如果没有先设计好交互，最后做出来的还是一坨屎，给再多 skills 也没用。
巨量的真实测试集和人工检查，是保证最终效果的核心，各种测试有用又没用。
Markdown 很适合 AI 做计划、记忆和长程执行，但 HTML 才适合人把握项目
Human in the Loop 会是一个相对长期的状态。人可能会越来越少写代码，但仍然要为 AI 做出来的结果负责。

我的几个关键错误经验：
产品设计应该在 SEO 设计之前，尤其应该在你被 Google 收录之前。
不要用 AI 生成的东西做测试，寻找真实的、用户会提交的内容做测试。
验证需求前，不要做太完善的后台系统。
请花更多的时间在搜索是不是已经有人很好的实现了这个东西了，以及分析你的优势是什么。
从小的功能点出发，打穿某个点，而不是做一个大而不精的东西。


为什么做 MarkOVO：
最开始只是因为我经常需要把文件交给 AI 处理。但之前 Cursor 经常打不开 PDF 。所以我想先把文件统一转换成 Markdown ，同时尽量保留表格、图片等原始文件等信息，感觉是有一定需求的，就开始干了。
文件只需要处理一次变成 md ，后面可以持续复用，这就是 MarkOVO 最开始的需求。
（当时我在 Google 上简单找了一下，感觉没有做的很好的产品，但我后来在 github 发现了 MinerU ，确实已经做的很好了，所以这又是一个重复造轮子的故事=-=）

AI 最大的问题，不是做不出来，而是什么都做
AI 不会拒绝需求。你让它加一个状态，它就加一个状态。更麻烦的是，它不仅什么都想做，还什么都想展示出来。
之前在 x 上看到这样的一段：你让 AI 做一盘炒面，它端上来一锅炖牛肉。
你：“不要炖牛肉，我要炒面。”
AI：“OK ，下面是你的 炒面制作思路（没有炖牛肉版）.md”

AI 不知道什么是对错、不会删除那个错误的思路，而是把“为什么不做炖牛肉”也变成产品的一部分。这一点在做 UI 时尤其明显，所以做 AI Coding ，不能只是不断告诉 AI 要做什么，还要明确告诉它什么不应该出现（而这需要更多的时间和精力投入）

测试覆盖率 90%，结果照样可能不能用
AI 很擅长在自己的边界里完成任务。
你让它做 A 、B 、C 它做出来，然后测试 A 、B 、C 告诉你全部通过。
但真实用户不会按照这个边界使用产品，真实的情况往往才是现实而复杂的

在完成了一个真实文件测试集后，我发现 AI 宣称已经没问题的文件转换系统就是一坨屎，诸多问题例如：
表格成功提取了，但行列关系乱了；
图片和文字都还在，但图片位置和对应内容对不上；
对于公式部分处理的异常（甚至做的时候完全不知道）
........
这些问题都无法在自动化测试中检查出来——AI 的自动化测试验证的是：系统有没有按照写下来的规则运行，然而它本身就预设了“完成边界”
所以我们人工需要验证的是：这个东西到底符不符合真实用户的预期。

所以我现在认为，一个部分的“完成”至少意味着：代码完成、worktree 合并，成功部署，并且人工检查过最终效果，这样才算完成一个部分的更新。

延伸来说，未来 AI 开发里一个可能越来越重要的一个问题是：到底什么时候才算 OK ？
AI 不会主动停下来。只要继续给它时间，它永远可以再重构一次、再做一轮优化。写代码的成本，真正困难的反而是定义产品与边界本身。

Markdown 适合 AI ，但不适合人掌控项目
Markdown 很适合 AI 工作。
需求的计划文档，过程的进度文档，问题的文档整理.....AI 可以在任何时候继续使用这些文档、这个范式对 AI 很有效，但对人却并不友好。
在现在，一次长程任务可能连续执行五六个小时。AI 交给你审批的大量计划，里面充斥着各种信息、它创造的概念。在读文件的时候，很难理解它说的每一个 Gate 、Layer 或 Package 到底是什么。

这样的结果就是，人只能扫一遍，说“看起来没啥问题”

但随着项目发展，项目开始超出你的认知边界，这种“看起来没问题”，就变得越来越难以把握了。甚至说，AI 说“完成了”，可能只代表代码在本地写完了。它不一定已经合并，不一定已经部署，甚至可能部署失败了，而这种持续推进的过程带来了人的迷失。

所以我现在开始构建和使用 HTML 控制台。通过这种更可视化的方式，把握我们下一步要做的这个计划中几个关键点是哪些、以及我需要把握的之前的项目与实际情况。
Markdown 是 AI 的工作区，HTML 才应该是人的控制台。

人会越来越少写代码，但持续 in the loop
以我目前在一线互联网里看到的情况，说 90% 以上的代码由 AI 生成，可能是一个相对保守的说法。程序员更多是在做架构判断等，很少动手敲代码。

而在 MarkOVO 里，因为我不会写代码，所以也不会做任何代码 review 。我的判断只能往结果端走：最终结果能不能用、各种状态提示是否合理等等
理论上，除非我们能在项目开始前就把所有要点、边界和验收标准想得非常完整，再配合高度自动化的验收程序，才有可能把人工介入降到很低。但无疑这种自动化的前提是成本极高的；更现实的方式，还是让人在执行过程中持续介入，在关键节点检查结果，尽量保证 AI 最终产出的东西看起来没有问题。

这也是为什么我觉得 Human in the Loop 会长期存在——本质上，人仍然要为 AI 做出来的东西负责。

我还没有完全解决的问题
一个人通过 AI 管理几十万行代码，最难的不是继续增加功能，而是怎么保证项目没有脱离自己的控制。
这里的根本的问题是：当一个项目越来越多的部分已经超出我的认知边界，我无法理解它，也无法给 AI 足够正确的建议时，我要怎么继续驱动它往前走？
这就是我目前现状、也可能是 AI Coding 接下来很重要的一个问题；随着 AI 能够完成的事情与来越多、成本越来越低，那么必然有更大量、各行各股的普通人使用这样的方式，来构建一个更复杂的产品。
坦白来说，对当前项目各类的系统，我都是相当一知半解。

于我自己来说，这可能也意味着另一件事——AI 可以降低写代码的门槛，但它并不会完全消除学习的必要。项目越往深处走，我可能还是需要补上足够的知识，至少让我知道哪些地方不能只相信 AI 。