AI 实践：开发、架构与内容创作

2023 年，我开始使用 Gemini，后来成为长期年费用户，也一直保留着 Notion AI。到了 2026 年，Codex 和 ChatGPT 逐渐进入我的日常开发；在常用接入渠道受限时，我也会切换到 Claude Code。

这些工具陪我处理过不同类型的工作：写代码、讨论系统设计，以及尝试通过 Agent 帮创始人打造企业家 IP、准备口播稿。

用得越久，我越在意一个变化：原来有些想法会停在“这个我会不会做”，现在更容易先迈出一步，去讨论它应该怎样做、值得做到什么程度。

一、从持续使用，到按任务选择工具

持续订阅让我有机会把 AI 放进日常工作，观察它在反复修改和不同任务中的表现。一次回答惊艳，并不足以决定一个工具能否长期留下来；我更关心它能不能陪我把事情继续推进。

目前，我常用的模型包括 ChatGPT 环境中的 6 Sol、Claude Code 中的 5.5 Haiku，以及 Gemini 3.1 Pro。版本会继续变化，下面记录的是我的使用感受和选择逻辑。

这些选择来自个人任务与偏好，没有经过控制变量的模型评测。尤其是“文案更有人味”，包含了我对语气和表达的主观判断，也受到输入材料与修改要求的影响。

一个月的实际调用记录

下面是我在 2026 年 9 月使用其中一个 AI 接入平台的统计截图：当月共有 45,118 次请求，平台统计的总 Token 约为 49.5 亿，显示的实际消费约为 674.23 美元。它记录了 AI 已经进入我日常工作、被持续调用的一段经历。

这里的总 Token 包含约 42.7 亿缓存 Token，不能全部理解为新生成的内容；消费金额也以该平台的计费口径为准。这张图只覆盖该接入平台，不代表我在所有 AI 工具上的完整用量。

调用量让我能在大量实际任务中反复观察工具，但工作是否有效，最终还是要看代码能否通过验证、方案能否落地，以及内容能否被采用。

二、GPT 让我把更多注意力放到架构上

过去面对一个功能，我经常先判断自己是否熟悉对应技术、有没有足够时间把它写出来。实现成本会提前限制想法的范围。

引入 Codex 和 ChatGPT 后，实现变得更容易启动了。陌生的框架、以前没有写过的交互，或者需要跨多个模块修改的需求，都可以先拆开，再逐步推进。

那种感受很直接：好像没有什么功能不能尝试，甚至会有一点“世界尽在掌握”的兴奋。

我把这种感受理解为尝试边界的扩大。功能能够被写出来之后，仍然有很多判断需要完成：业务规则是否成立，模块职责是否清楚，状态应该放在哪里，失败后如何恢复，以及后续修改会影响哪些地方。

因此，我可以把更多精力放在架构和取舍上。代码生成的速度越快，越需要有人明确本次要解决的问题、必须遵守的约束，以及可以接受的结果。

AI 让我更敢去尝试一个方案，也让我更清楚，架构设计和结果验收需要持续参与，不能只停留在最初的一次提问。

三、一次真实修复：与 AI 协作梳理 MQ 消费事务边界

在 RegenBio 报告系统的一次排查中，我遇到了一个具体问题：报告审批通过 RocketMQ 异步流转，消费逻辑抛出异常后，数据库中的变更却没有按预期回滚。

这次需要处理的是消费端的本地数据库事务，而不是 RocketMQ 事务消息机制本身。消息重试与数据库回滚分别由不同的机制负责，异常能够触发重新投递，并不代表之前的数据库操作已经撤销。

从故障现象追到调用链

我先让 AI 阅读消息模板和报告审批监听器的代码，分析可行方案。它沿调用链区分了两个边界：发送端已有事务提交后发消息的设计；消费端则由公共监听器入口直接调用业务消费方法。

报告监听器虽然声明了 @Transactional，但继承的入口和内部调用方式，使这段业务逻辑是否真正经过 Spring 事务代理成为排查重点。AI 据此提出在公共消费入口显式管理事务，并指出失败状态写入、异常重试和通知发送之间还有需要分别处理的问题。

这里有价值的协作，是把“抛异常为什么不回滚”拆成可以检查的调用路径、事务边界和副作用，而不是看到事务注解就认定它一定生效。

我的取舍：先统一能力，控制业务改动

AI 最初提出了更完整的调整方向，包括拆分审批业务服务、整理失败语义，以及调整通知发送时机。我没有一次性推进所有重构，而是先确认：能否只在 core 层补齐 MQ 消费事务契约，再让 Report 接入这项能力？

这样选择，是因为事务执行属于多个消费者可以复用的基础能力。先将它收敛到公共入口，可以减少各个业务监听器对注解和代理调用方式的隐含依赖，同时控制这次故障修复涉及的业务范围。

最终采用的方案是在公共监听器中增加按需开启事务的开关，由 TransactionTemplate 包裹业务消费方法。默认保持原有非事务行为，需要本地事务的监听器显式开启；异常继续交给 RocketMQ 处理重试。显式要求事务却缺少事务管理器时，则直接报错，避免静默退化为无事务执行。

Report 先切换为这套消费事务能力，保留原有审批业务结构。修复目标因此比较明确：先让消费失败时的本地数据库回滚有一个统一、可测试的执行边界。

从单点修复到同类检查

完成第一处修改后，我继续要求 AI 检查其他监听器，判断哪些也需要事务。检查范围扩展到了授权、框架、基础设施、报告等模块中的消费实现。

这里没有把所有监听器一律开启事务。涉及本地数据库状态写入的消费者接入统一能力；纯缓存刷新和配置刷新不需要数据库事务；邮件、短信、文件上传等外部动作，也不会因为开启本地事务就获得回滚能力。

对话中的执行记录显示，公共组件补充了提交、异常回滚，以及缺少事务管理器时立即失败的测试，组件测试通过；Report 和后续调整涉及的多个业务模块也完成了编译检查。

验证到哪里，结论就写到哪里

这些记录支持公共组件的事务执行测试与业务模块编译已通过，还需要在真实业务链路中验证消费异常后的数据库状态、消息重投与通知行为，才能判断业务效果。

本地事务也不会自动解决重复消费、重试耗尽、外部调用副作用，或数据库提交与消息发送之间的故障窗口。审批失败状态应该回滚还是保留、通知应该何时发出，都需要按业务语义继续设计。

这次协作中，AI 帮助阅读跨模块代码、梳理候选方案并执行修改；我持续决定修复目标、公共能力的归属、变更范围和验收边界。比起一次生成多少代码，这更接近我希望展示的 AI 工程协作能力。

四、这个网站，也是一次持续的人机协作

这个个人网站就是一个具体例子。文章、项目案例、履历、国际化和深色模式，是在连续讨论与修改中逐步形成的。

其中很多要求，最初只有一个方向。例如，希望页面更接近日系网站的气质，希望项目介绍体现业务，希望文章阅读结束后的推荐与返回操作更清楚。

这些要求需要在实际页面中继续明确：哪些内容先出现，哪里应该保留留白，哪些分割线没有必要，以及同一类按钮是否真的对齐。

文章底部的调整尤其典型。先确定“相关案例”和“继续阅读”左右排列，再收敛为相同样式的横幅；随后将栏目名移入横幅，缩小内容标题、限制单行省略，最后修正分享与返回按钮的水平对齐。

“左右排列”只解决了结构问题。视觉层级、文字密度和操作关系，还需要通过页面效果继续判断。AI 可以帮助修改代码，我仍然需要指出具体哪里不成立，并在下一轮结果中确认它是否被解决。

这段过程让我对协作的理解更具体：提出方向之后，还要能够观察结果，把不满意的感受转成可执行的修改要求。

五、做口播内容时，我更偏好 Gemini 的表达

开发之外，我也尝试操作 Agent，协助创始人打造企业家 IP，口播稿是其中一类工作。

这类内容需要适合一个真实的人开口表达。观点是否清楚，句子能不能自然说出来，语气是否贴近本人，以及听众能否跟上，都影响稿件能不能使用。

在这类任务中，Gemini 给我的感受是文字更有人味，AI 味更淡。我通常更愿意以它的表达作为继续修改的起点。

但“读起来顺”还不足以决定稿件可以交付。创始人是否认同其中的判断，材料能否支撑观点，有没有把推测写成事实，仍然需要人工确认。尤其是个人经历、企业成果和具体数据，不能为了让故事完整而由模型补齐。

这也解释了为什么我会同时保留多个工具：开发与口播对结果的要求不同，我愿意根据任务选择更合适的协作方式，而不是要求一个模型在所有场景中都采用同一种表达。

六、我希望展示的是怎样的 AI 能力

持续使用这些工具之后，我更看重三件事：能否把模糊的想法说清楚，能否让工具在已有约束内推进，以及能否判断结果是否达到要求。

在开发中，这些判断落到业务边界、架构设计和验证上；在内容工作中，则落到受众、事实和表达上。模型可以参与其中很多步骤，最终仍需要有人决定哪些结果可以留下。

个人工作中的 AI 协作，与把 AI 做成可持续运行的业务产品，也有不同的要求。LAIFE AI 项目案例记录了健康资料、AI 助手与服务运营如何连接；《AI 时代的软件工程：规格、约束与验证》则进一步讨论了如何检查 AI 实现。

我愿意继续尝试新的工具。AI 已经让我更容易把一个念头推进到可以看见、可以讨论的阶段；接下来，仍要把它打磨成真正适合使用的结果。