一个文科生用 AI Agent 搭了三个软件产品：方法论与反思
我没有读过计算机系。我的背景长期偏向人文社科，在此之前和之后，我对编程的理解长期停留在”能看懂逻辑、但无法独立写出工程级代码”这个层次。
2025 年底到 2026 年初的半年时间里，我用 Claude Code 和 Gemini 这两个 AI 编程助手，从无到有搭建了三个完整运行的软件产品：
- 语文教学辅助工具：面向教师减负场景，含作文批改、阅读训练、古诗默写、快速备课等功能模块；
- 英语学习辅助平台：面向 K-12 学段，包含 AI 对话、作业批改、写作辅导、兴趣词汇、阅读训练、视频学习等模块；
- 私人投资研究验证系统：把投资研究假设转化为回测、样本外验证、风险报告、数据看板和负证据记录，只用于研究纪律与方法复盘。
三个项目都不是玩具 demo：教育工具已进入真实使用场景，研究验证系统则只提供研究提示与风险审查，不构成任何买卖信号。
我不是在说”AI 让编程民主化”这种口号。我想说的是更具体的东西：一个没有工程背景的人，在 2026 年，如果掌握了正确的编排方法，能做到什么，又做不到什么。这里说的工具主要是官方意义上的 Claude Code 与 Gemini API 这类可编排模型，而不是单次聊天式问答。
三个产品：从问题出发
Chinese Athena：从一位老师的抱怨开始
这个项目的起点不是技术，而是一句抱怨。一位语文老师说，每次批改作文要花三四个小时，还要一字一字辨认学生的手写字迹。作文批一半，手腕已经酸了。
我从这个具体的痛点出发，问自己：这个流程的哪些步骤是可以机器化的？
答案是大部分。手写识别（OCR）可以用 Gemini 来做，它对中文手写的识别质量出人意料地好；错别字检测有 PyCorrector 这样的工具；评分和升格建议则是大语言模型最擅长的事情。整个流程：图片上传、OCR 识别、错字标注、AI 评分、生成 Word 报告，每一步都有现成的工具可以调用。
从第一次 commit（2025 年 12 月）到现在，Chinese Athena 已经长成了一个有二十个功能页面的 Streamlit 应用。commit 历史里记录着这个过程的每一个节点，从最初的作文批改脚手架，到 Gemini OCR 集成，到语文神器 v2 重构，到 DeepSeek 片段仿写的 A/B 并行对比——每一步都留有据可查。
看这条线索，可以感受到产品不是设计出来的，而是在使用中长出来的。老师用了 OCR 之后说，能不能也帮我生成导学案？用了导学案之后说，能不能追踪学生的薄弱项？每一次使用都带来新的需求，新的需求驱动新一轮 AI 辅助开发。
最近一次重要迭代是加入高中学段支持。commit 记录很克制：新增高中语文扩展能力。背后是对原有架构的一次非破坏性扩展——初中工作流保持默认，高中能力作为加法叠上去。这个决策本身不难，但如果没有从一开始就保持清晰的模块边界，这种扩展会非常痛苦。
私人研究验证系统：把研究体系工程化
量化指标系统是三个项目里最复杂的一个，也是我花时间最长、踩坑最多的。
项目从一个很小的研究脚手架开始，后来逐步长成包含验证、风险、可视化和审计边界的系统。
这个项目的核心挑战不是技术，而是认识论。Wyckoff 方法是一套关于市场结构和主力行为的理论框架，用文字描述起来直觉上很清楚——“弹簧测试”、”最后供给”、”量价背离”——但要把这些概念转化为可计算的指标，需要大量的精确定义。
一个典型的例子：什么叫”价格结构已经出现背离”？直觉上似乎清楚，但代码里需要明确观察窗口、确认条件和失败定义。这些判断背后是对市场行为的理解，AI 写不了，必须由人来给出。
真正的工作量在回测体系的建立。从单信号胜率统计，到市场环境分类（牛市/熊市/震荡），到 walk-forward 验证防止过拟合，到 DSR（Deflated Sharpe Ratio）多重检验，每一层都是在用数据审问自己的直觉。
一个典型迭代，是为不同资产类别建立关键词和来源标签体系，用于新闻、行业语义与研究主题的匹配。这是纯粹的领域知识积累工作，AI 能帮我写代码，但无法帮我判断不同品种在宏观叙事中的差异。
项目最终形成了一套完整的研究闭环：研究假设、批量验证、样本外检查、执行成本敏感性、风险报告、负证据记录、可视化看板与来源审计。它的价值不在于对外输出信号，而在于训练我如何约束自己的判断。
English Athena：最短时间内的最快交付
English Athena 是三个项目里建设周期最短的——从第一次 commit 到可用状态只用了几天。
这一次的交付记录很短：复用已有框架，先做出可用版本，再根据真实学习场景补功能。
这一次快速交付的原因很简单：Chinese Athena 是它的模板。同样的 Streamlit 架构，同样的 Gemini 调用层，同样的部署方式。第一个项目解决了脚手架问题，第二个项目可以专注在产品内容上。
这种可复用性不是提前设计出来的。它是在实际工程演化中自然沉淀的：当 Chinese Athena 里的 Gemini 客户端被第三次修改到足够稳定，它就自然变成了值得复用的组件。
核心方法论：我实际上在做什么
回顾这半年，我能总结出几个一再被证明有效的操作模式。
一、问题分解先于代码
一个可以被 AI 实现的功能，首先必须被人清晰地分解为子步骤。”帮我做一个作文批改系统”是一个 AI 无法有效回应的指令。”把手写图片转成文本，用 PyCorrector 标出错别字，用以下评分标准打分，输出结构化的 Markdown 报告”——这是 AI 可以执行的指令。
这个分解工作是纯人类的工作。它需要对问题领域的理解：知道作文批改的流程是什么，知道现有工具链的能力边界在哪里，知道哪些步骤对最终质量是关键的。AI 是执行者，不是问题定义者。
很多人误以为”AI 编程”的革命在于 AI 替代了思考。我的经验是相反的：AI 替代了打字和记忆，但对思考的要求实际上更高了。因为你的思考质量直接决定你给 AI 的指令质量，而指令质量的上限就是产品质量的上限。
二、领域判断力无法外包
Chinese Athena 的作文评分用的是广州中考 60 分制标准。这个决策——用哪套标准、权重如何分配、”升格建议”应当指向哪个维度——是领域判断，不是技术判断。AI 可以按照任何一套标准来实现，但不能告诉你哪套标准是对的。
私人投资研究系统里的验证规则更是典型。一个候选模式是否值得继续观察，不能只看漂亮胜率，还要同时考虑样本外表现、盈亏结构、交易成本、市场环境和失败年份。哪些维度应当进入验证门，哪些结果必须归档为负证据，这些都是投资哲学和风险意识驱动的判断，不是从数据里自动冒出来的。
如果你没有领域判断力，AI 会给你交付一个技术上完整、但方向上错误的产品。
三、迭代而非规划
三个项目都没有一份完整的初始设计文档。我从来不知道第一天的 “scaffolding” commit 最终会长成今天这个规模。
正确的方式是：先让一个最小可用版本跑起来，然后在真实使用中发现真实问题，然后用 AI 快速实现解决方案，然后重复。
这种方式有一个副作用：代码在某些时刻会变得混乱。Chinese Athena 经历了一次完整的重构：
7771a93 refactor: 全面重构 — 共享组件提取 + 性能优化 + Bug修复
这一次重构发生在功能已经相当丰富之后。原因是早期为了快速迭代，各页面之间大量复制粘贴代码，积累的技术债让新功能的开发变得越来越慢。重构是一次主动的清账，由我来识别问题、拆解任务，由 AI 来执行具体的代码层面的整合。
四、把 AI 当层次化的协作者，而非全能工具
我在实践中逐渐形成了一个模型：不同的模型适合不同层次的工作。
复杂的架构决策、高风险研究系统的逻辑设计、回测方法论的评估——这些需要深度推理，我会用 Opus。日常的功能实现、bug 修复、文档写作，Sonnet 已经足够。机械性的代码格式整理、批量的重复操作，Haiku 可以处理。
更重要的是，AI 协作不是单向的”我出指令、AI 执行”。当 AI 反馈说某个方案有潜在问题，或者给出了一个比我最初构想更简洁的实现，我需要有能力识别和采纳这个反馈。这种双向的智识交流，比任何单纯的指令模式都更有效率。
踩过的坑
诚实地说，这条路并不平坦。
最贵的教训是：禁止在未确认恢复路径前重启关键进程。 2026 年 3 月，在一次目录误操作之后，我犯了直觉上最合理但实际上致命的错误：重启了进程。一批长期积累的数据因此无法恢复。那一刻我明白，真正危险的不是不会写代码，而是不懂副作用和恢复边界。
从那之后，我对一切涉及不可逆操作的步骤保持近乎偏执的谨慎：先备份，先验证，再操作。这种谨慎不是技术问题，是操作纪律问题。
技术层面最常见的坑是”禁止双重并行”。 早期在优化扫描速度时，我在一个外层并行框架上又叠加了内层的并发执行，导致资源争抢和大面积超时。根因不是 AI 写错了代码，而是我没有先检查内层是否已经有并发机制。
最隐蔽的坑是幻觉验证。 AI 在描述”某功能不存在”或”某字段缺失”时，有时会自信地给出错误的负面结论。我把这个教训写成了一条规则：任何”X 不存在”的判断，落笔前必须用第二种独立方法验证。一次错误的负面结论导致我写了一份完整的修复计划——而问题本来就不存在。
对”AI Native 开发”的反思
2026 年关于 AI 编程的讨论有两种极端：一种是”AI 已经能替代程序员”，另一种是”AI 只是个高级自动补全”。我的实践让我站在中间某处，但更靠近后者。
AI 极大地降低了实现已知功能的成本。一个我能清楚描述的功能，从想法到可运行代码，时间从以天计缩短到以小时计。这是真实的生产力提升。
但”能描述清楚一个功能”这件事本身的难度没有下降。这需要对问题的深度理解，对目标用户的观察，对技术可行性的判断，对优先级的取舍。这些能力不能从 AI 那里借来，只能从领域知识和实践经验中生长出来。
所以更准确的表述是：问题分解能力 + 领域判断力 + AI 编排，在 2026 年已经可以替代传统编程技能，但不能替代思考本身。
一个有良好领域判断力的人，现在可以在没有工程背景的情况下构建真实运行的软件系统。这是货真价实的范式转变。但那些没有领域判断力的人，用 AI 一样会迷失——只是迷失得更快，因为 AI 会非常流畅地帮你实现一个错误的方向。
方法论总结
对于希望用 AI Agent 构建产品的读者，以下是我认为最有价值的几条操作原则：
1. 从最小可用问题出发，而非从完整设想出发。
不要先设计系统，先找到一个用户真实感受到痛的具体场景，做出能解决这一个场景的东西。规模是用出来的，不是设计出来的。
2. 把问题分解能力当作核心技能训练。
“让 AI 实现 X”的质量上限是你对 X 的理解深度。每次开发前，先用自然语言把功能分解成最小可执行步骤，再把这个分解交给 AI。如果你自己都说不清楚，AI 给你的结果就是猜测。
3. 保持代码可读性，因为你是代码的审查者。
AI 生成的代码，你必须能读懂。不是为了修改细节，而是为了审查逻辑：这段代码做的，是我想要的吗？可读性是你作为编排者的权力来源。
4. 建立不可逆操作的检查表。
任何涉及数据删除、服务重启、线上部署的操作，先停下来问：这一步是可逆的吗？如果出错，最坏的结果是什么？这种习惯不是保守主义，是工程纪律。
5. 用真实使用验证，而非自我验证。
把产品给真实用户用，哪怕只是家人或者同事。你在开发中看不到的问题，用户在使用中三秒钟就会遇到。真实反馈是最便宜的测试。
6. 分清”可以用 AI 做”和”需要自己判断”的边界。
实现已知方案：交给 AI。判断哪个方案是对的：留给自己。前者是 AI 擅长的，后者是领域知识的战场，也是你在这个系统里不可替代的位置。
我的几个项目都还在活跃迭代：教学工具继续扩展学段，私人研究系统继续强化来源与风险边界，英语学习平台也在补更多学习模块。这条路没有终点，只有下一个迭代。
这套方法后来也进入了本站的内容系统：从 sources、wiki、候选队列到 WordPress、WeChat、X 与 SEO 审计，核心仍然是把复杂工作拆成可验证的步骤。相关的公开运营入口可以从 AI Agent Native Workflows、Policy Foresight And China Macro 和 Investing Discipline 继续读。
有时候我想起在浙大的那段时间，读的是基督教与近代中国这个课题，花大量时间辨析档案里相互矛盾的史料，试图在碎片中拼出一个说得通的历史叙事。那套工作方法——从原始材料出发、抵制诱人的简单结论、在混乱中保持结构性思维——在今天的工作中出人意料地有用。
或许问题分解能力不是工程师的专利，而是任何认真对待一个领域的人都可以训练出来的东西。AI 工具只是让这个能力的生产力乘数变大了。
FAQ
没有计算机背景的人真的能用 AI Agent 做产品吗？
可以，但前提不是”让 AI 替你思考”，而是你能把真实问题拆成清晰步骤，并且能读懂生成代码的大致逻辑。AI 降低的是实现成本，不会替代领域判断、用户观察和风险控制。
AI Agent Native 开发最容易失败在哪里？
最容易失败在两个地方：一是把模糊需求直接丢给模型，得到看似完整但方向错误的系统；二是把不可逆操作交给自动化，缺少备份、验证和回滚意识。越是使用 AI，越需要工程纪律。
作者：sustine.top | 公众号：柔和谦卑 履责 求知（sustine_et_abstine）