用大模型开发FS一个半月的心得：认知、Agent与Harness

OK，总结一下最近开发 FS 的一些心得。

背景：从 Sonnet 到 V4 Flash 正式版 #

最近一个月（准确说一个半月）开发 AFS，从 Claude Sonnet 切换到了国产 DeepSeek V4 Pro 模型，而且用的是 V4 Pro 的预览版。昨天（8 月 1 日）用上了 V4 Flash 正式版，效率提升了不少。

Claude Sonnet 为什么不用？因为太贵了，不耐用。

预览版这一个半月里，中间反反复复回归，折腾了不少问题。流程走得并不顺，很多测试反复跑全流程，总是不通顺。前天晚上发布了 V4 Flash 的正式版，昨天一整天用下来，即使是 Flash，优化后的并行测试也全部通过了，而且跑了两遍。

一、模型可靠度与开发者认知，是互补的 #

从”一无所知地去使用大模型”（连 VS 都不太熟），到”有一些概念但理解不深地去使用”，再到”理解了流程、理解了概念地去使用”，最后到”深入理解、深入掌控整个流程地去使用”——这几个层次，对大模型的依赖程度是完全不同的。

顺便提醒：越是无知，越要谨慎地使用模型，否则后面返工可能就越频繁。

大模型的可靠度，比如它的 Agent 能力、Harness 能力，在一定程度上（注意，是一定程度上，不是绝对）对开发者是有互补作用的。模型的可靠度越高，对开发者的辅助性就越大，释放开发者的心脑程度也就越高。

关键风险在于：如果自己一无所知就去使用大模型，大模型本身也可能是错的。 它的知识大概率是对的，但并不完全对，特别是专业领域——比如一些工具的调用、一些流程的认知。开发者如果连这些最基本的正确认知都没有，就堆上去用，后面累积起来的架构问题、流程问题，可能会导致整个服务不可用、不可调试、不可测试。

举个例子：我在用 V4 Pro 的时候，即使是 Pro 版本，它写出来的流程也总是”掉链子”。后来发现，它对一些工具的调用没有正确的资料，或者根本没意识到要先去主动了解怎么正确使用领域内的工具——毕竟这些工具的使用可能并不在它训练的数据里。这种情况下，就需要开发者去指导它怎么了解，或者直接喂它一些提示词、给它正确的使用例子。这样 LLM 在调用最基础的语言能力的时候，就有一个很好的开始了。

二、第一点：对 FreeSWITCH 内部流程与边界要有自己的认知 #

这一点要展开说两件事。

1. 模糊的认知交给预览版大模型，踩坑在所难免 #

自己对于整个 FreeSWITCH 内部流程工具的认知、边界的认知、ESL 使用的认知、全流程测试中每一步的认知，由于并没有亲自把每一步实际用一遍、踩一遍坑，所以是一个模糊的状态。而把这个模糊的认知交给大模型，而且是交给一个预览版的大模型——大模型自己本身就不是 100% 靠谱，能达到 80% 算够高了，而这个月用的预览版 V4 Pro，可靠性大概只有 60%。这一个月来依赖它开发，踩了不少坑，回归了不少，浪费了点时间。心理路程还是蛮折腾的。不过代码还是有产出的，流程也跑出来了，只是不顺而已。

2. 开发者 meta 认知，是流程架构的支撑和坚定的基础 #

开发者本身的 meta 认知和正确掌控，为后续的流程架构提供支撑和坚定的基础。

拿实际项目举例：我开发用的是 Go 写的 ESL（Go ESL），这在开源里并不是特别常见。走全流程测试时发现不顺，一个显而易见的问题，就是对 ESL 的连接使用、API 的调用，在认知上并不一致。所以我必须告知大模型：正确调用使用 ESL 的模式是什么、里面的 API 怎么调用怎么返回，这里不能多一个前缀，也不能少一个前缀。我就从最基本的工具调用开始，去生成校验、跑基本的测试，生成正确使用的文档，然后作为后面测试流程的基础，纠正最基本的认知——这才是最重要的。

三、第二点：Agent 能力，是半路开发者的效率杠杆 #

另一个是工具能力：大模型 Agent 特别是在 coding 方面的可靠度，对于一个不是小白、但也不是在专业领域深究的开发者——比如我这种半路进入 FreeSWITCH 开发的人——在很大一部分程度上决定了开发的效率和进度。

但不管是预览版还是正式版，大模型在开发效率方面所给的提升，以及心脑的释放，是显而易见的。

四、Harness 能力：上下文管理才是真功夫 #

还有另一个开发中的体会，是 context（上下文）管理，也就是 harness 能力。

即使是现在一兆上下文的模型，跑测试会产生不少日志，很容易把上下文堆满——可能一兆跑不到 10 个测试就满了。所以几个会话之间，或同一个会话里，上下文差不多满了的时候，就要做 handoff、做 compact，避免上下文溢出。这中间就遇到了很多次溢出，导致的后果就是规划不可用。

如果只是纯 compact，它可能会忽略掉一些关键的基础上文信息。所以我一般在 compact 之前会先做一个 handoff，让它生成一份上文的内容，保存到文件里面。然后在 compact 的时候，它会主动去读取这个上文文件，这样就可以很大程度地复用上文的一些有用信息了。

为什么要生成上文到文件中呢？ 因为 compact 的时候大模型会丢失很多东西，在 compact 的过程中，上文和新会话之间不能很好地处理这种上文的传递关系。最直观的一个感受就是：compact 之后跑新任务，明显感觉在”掉链子”。所以这里就手动地、显式地指定了上文保存的文件，compact 之后再读取上文文件就行了。其实这也算是 harness 能力调优的一个要点。

我自己刚刚进行了一次 handoff + compact，发现在 compact 的过程中它会自动地检测到这个上文文件——也可能它自己检测不到，就会自己生成。所以说 V4 Flash 在 Agent 能力方面的提升，如官方所说，是显而易见的。

skill：必须在自己项目的坑里长出来，没有一劳永逸的通用工作流 #

除了用 handoff 中间文件来传递上文，我还生成了一个最基本的”基础开发 skill”的上文载入，比如环境、ESL 的工具调用、API 如何使用等。在开发 FS 工作流的过程中，也生成了一些 skill（handoff、injecting-pitfall-memory、loop、brt-debugging、full-flow、full-test、claude-handoff）：

full-test：全流程测试。
brt-debugging：先复现测试，发现问题、定位，然后再改代码。
new test：新建测试。这里新建测试有一定的要求，比如新测试要与旧测试可以并行地执行，所以有一些参数上面的隔离性，这些要求就写到 skill 里面。
FAQ / pitfall：把一些容易踩坑的点记录下来，防止后面重复踩坑。
loop 工程：其实就是这个领域开发的一个自动化工作流——目标是什么？如何执行？如何发现问题并反馈？反馈之后如何修复？然后重新开始，直到达到目标。

但这里最值得强调的一点是：工作流只有根据自己的实际项目去制定，才能大大提高效率。 因为工作流的价值来自具体项目，而不是来自通用性。

原因在于，这些 skill 沉淀的全部是这个项目独有的细节——这个领域的工具怎么调用（ESL 的 API 前缀、连接模式）、测试怎么并行、环境怎么搭、坑长在哪些地方。这些信息不在模型的训练数据里，也不在任何一份”通用 best practice”里，只能从一次次跑不通的测试、一次次回归中踩出来，然后写进 skill，让下一次不再重复踩。所以与其期望一套通用的工作流套用所有项目，不如根据手头项目的实际情况去定制——量身定制，才能最大化效率。