3
3
寒假期间和三月初使用claude code和opencode做了一下项目，包括：
- 修改博客：重构博客底层的数据接入层；
- 算卦：六爻的基础计算。
我使用的是阿里的Qwen3，当时Qwen3.5还没出，所以现在的结论就有点过时。由于学生有300元的免费额度，最开始的时候，我直接使用按量计费的套餐，主要使用30B模型，搞不定的时候用200多B的模型，五天就300元就烧完了，约千万级Token，只能说太贵了烧不起。后来使用订阅制套餐，我不敢用在比较重要的项目上面，因为套餐要求产生的数据会用于训练。
使用总体感受
目前我的最佳实践是在使用claude code和opencode（以下简称Agent）之前，先在网页的对话窗口里描述基础需求，生成技术说明书，包括主要功能描述，class和函数定义。然后将文档粘贴并修改改docs/spec-xx.md。最后，让Agent读取文档实现，同时需要实现单元测试。在实现前，可以先询问是否有哪些部分定义不清晰。
其中一个需要重点把握的是，你需要控制实现功能的复杂度，主要有以下的原因：
- 一口气实现多个彼此独立的功能会占用大模型的上下文机制，过长的上下文会占用有限的Attention带宽，严重降低性能。（下一节会详细阐述复杂度的影响）
- 在Agent运行过程中，很难和Agent讨论具体是如何实现的（因为一般会开启自动模式），因此大模型实现其实是瀑布开发模式。这种开环的开发模式很容易在过程中发现新的问题，模型自主尝试解决，人无法干预，最终导致出现问题后的所有实现不符合预期。我们知道删代码比写代码更难，（因为删代码是复杂度更高的任务），大模型无法自动删代码，只能手工删除，最终花费更多的时间。
因此，你需要仔细权衡功能复杂度：太简单的功能，琢磨提示词的时间都写完了；实现复杂的功能，大概率包含不符合预期的实现，而模型改代码，尤其是删代码的性能其实是很差的。所以，一个好的Agent任务，需要满足以下的条件：
- 复杂度适中，能节约你的时间，实现符合预期。
- 过程中的风险是可控的，不会跳出新的问题，导致模型出现意外的修改。 以上只适用于需要不断演进的工程项目，以下情况是例外，对于一些不需要持续维护的项目，比如一些基础设施（GCC、JSv8、数据库等），从一个语言翻译到另一个语言，并且有完整的测试用例，确实可以尝试一口气全部做完。
其它问题1：工程中的问题
我的博客底层数据模型为了兼容以前的数据库模型，同一个字段在不同层的名字不一样。比如，主题在数据接入层叫Topic，但是在数据库的模型层叫Tag。但是大模型不知道这是同一个东西。因此，你必须显式地描述数据库各个字段的映射关系，让模型读文档，否则模型根本无法通过读代码理解。开启思考模式也不能保证将这种隐性知识保留在思考过程中。此外，这些说明性的文档多了以后，会占用大模型的注意力，导致写代码的性能会下降。
总的来说，就是如果你的项目没有文档，大模型是基本干不了一点的。即使有文档，如果隐性的遗留问题特别多，可能导致模型的注意力被完全占用，最后要么是处理不了复杂问题，要么是输出不符合要求的代码。
其它问题2：边缘场景和其它问题
对于编写六爻来说，模型最大的用处就是生成六十四卦的unicode和六十四卦名字的数组。这在过去需要手敲，一个一个拷贝，但是模型可以一瞬间生成。只是这个工作在网页端就可以完成，不需要使用Agent。
我想让它按照二进制生成六十四卦的顺序，即坤䷁为000000，为第一个，水雷屯䷂为010001，为第33个。但是Agent不行，无法理解该需求。它在需要逻辑推理并且训练集不存在时，就很难自己推理，完成不了。此时需要尝试把思路固化成文档，更好的选择是直接手敲。
有的时候，模型生成了测试用例，然后发现怎么改都通过不了，然后就把测试用例删了，很无语。
复杂度问题
最近在尝试自己做Agent，自动化简单任务，我发现大模型工程最困难的其实是上下文管理。这里提出一个假说，模型的注意力是有带宽的，（比如受限于Token维度，但是现在很多模型架构有魔改，没有一个定量的评价标准），当上下文的复杂度过大时，模型的性能会严重下降。
上下文的复杂度体现在两个方面：
- 需完成的任务本身很复杂，即内在复杂度高：比如你不可能让模型制定并完成登月计划，让它自己去赚钱，自己采购等等。它涉及方方面面的事情，从资金准备、技术设计、实现、验证、最后执行计划。如果任务超出模型能力范围，它也完成不了。
- 语言描述很复杂，即形式的复杂度高：模型必须读入自然语言，输出自然语言，在输入上下文时要么是存在冗余信息，要么是缺失信息，需要模型自己猜测，导致占用注意力带宽。最终导致任务性能下降。
为什么将所有上下文传入模型，和上下文自动压缩机制的效果都有限呢？前者包含很多与任务无关的信息，会占用模型注意力；而后者在任务的特定步骤有效，但是当任务角度改变时就无法提取有效信息。举个例子，比如上下文为“有一个橙色的瓶子”，针对数数任务时，模型将其压缩为“一个瓶子”；但是当任务变为识别颜色时，此时的上下文就没有颜色信息了。因此，需要的信息需要根据任务从上下文中压缩。但该机制很难实现：在一个长程任务中，很难识别何时应该重新提取有效信息。
以一个真实任务为例，我需要使用大模型分析试验数据，一方面需要传入csv文本数据，另一方面，需要传入论文的研究背景，仿真背景和分析思路。首先，csv的原始数据包含大量噪声，模型根本无法提取有效信息，甚至不如先让模型生成py脚本画个图，然后调用多模态功能分析图片曲线的发展趋势。其次，论文的仿真分析有行文逻辑，比如第一节分析现象，第二节对比方法性能等等，侧重点不同。因此，需要在上下文中注入有效的方法信息，分析侧重点，但其实这个提示词是非常难写的，有的时候你自己把思路写清楚，答案自己就知道了。最后模型只能干润色工作。
适用任务和流程
虽然现在模型、OpenClaw吹得很凶，但在我看来，任务内在的复杂度并不会消失，大模型替代的是一些程式化的流程性的任务。一个好的视角是记录一天的任务，分析哪些任务是流程性的任务，可以自动化，哪些是一次性的、或者复杂任务，需要手动完成。
然后你会发现，可能20%以上的时间和注意力都是被微信占用，你需要识别哪些信息与你相关，然后处理情绪波动。剩下的可能有30%是程序化的工作。可能大模型替代的工作并没有想象中那么多，也没有那么少。
更重要的是，构建反馈循环，你需要持续地识别哪些可以自动化，自动化后哪些流程可以改进，然后聚焦于真正重要的部分，也就是决策、处理例外情况和承担责任。
对于Agent本身，我个人不会做长程任务，特别是24h不停运转。但是代码review自动化、生成测试用例还是不错的。
六壬/六爻工具
我在网站上线了六壬和六爻的工具，我发现将六壬盘面或卦的信息作为大模型的输入，用于一些新闻分析有奇效。我是这样理解的，古人对于事物的变化有一套独特的理解，他抽离了事物表象，提取核心要素，然后模拟了大道的流转，最后解码得到结果。通过数的计算和取象就能够获得事情的起始、发展和结局全过程预测。我从不关心吉凶，毕竟你不会因为凶就不去做了，更多的是降低风险。而这东西可以模拟事物的发展，探测潜在的影响因素，有助于完善计划。
我非常不推荐用这玩意炒股，就是你如果相信天人感应，那同样也相信阴阳平衡，从鬼神赚来的钱，总会通过其它东西还回去，得不偿失。同时提醒一句，大模型解卦经常有错，如果你相信占必应，也要注意人算不如天算。