AI写500行文档为什么总失忆
作者：微信文章AI 写 500 行文档，为什么总是写一半就"失忆"？
fast-edit 如何解决 AI 长文档写入困境
◆◆ 问题：AI 生成长文档的写入困境
你有没有遇到过这种情况——
让 AI 帮你写一份需求文档，它分析得头头是道，结构清晰，内容详实。然后到了写入文件的环节，文档只写了一半就断了。
这不是 AI "偷懒"，而是一个真实的工程问题。
在我开发 task-opencode（一个 AI 驱动的任务管理系统）时，设计了一套完整的"设计工作流"——需求文档、架构设计、功能列表、API 文档，全部由 AI 自动生成。听起来很美好，但实际跑起来，文件写入成了最大的绊脚石。
◆◆ 三种写入方式，三种翻车姿势
◆ 姿势一：Write 工具直接写
这是最直觉的方式。AI 生成内容后，调用编辑器的 Write 工具写入文件。
翻车现场：Write 工具对超长内容会卡在 pending 状态，永远不返回。一份 800 行的需求文档，Write 工具直接"失联"。
◆ 姿势二：heredoc 重定向
cat <<'EOF' > docs/REQUIREMENTS.md # 需求文档 ## 1. 功能需求 ...（省略 800 行）... EOF
翻车现场：AI 的 token 输出有上限。当 heredoc 内容超过约 150 行时，bash 执行会超时。文档被截断，你得到的是一份"半成品"。
◆ 姿势三：SSE 流式拼接
通过 SSE 流式响应收集 AI 的输出文本，在后端拼接后写入文件。
翻车现场：AI 在回复中可能不会完整输出文档全文，而是先说"我来帮你写"，然后调用工具去写——SSE 流拿到的只是 AI 的"旁白"，不是文档本身。
◆◆ 核心矛盾
AI 生成的文档通常 500-1500 行，但 AI 的单次工具调用对大文本的承载能力有限。
这不是某一个工具的 bug，而是 AI 工具链在处理「大文件写入」这个场景时的系统性短板。
◆◆ 解决方案：fast-edit 分段写入
fast-edit 是一个专为 AI 场景设计的文件编辑工具。它的核心思路很简单——既然一次写不完，就分段写。
◆ 分段 heredoc + cat 合并
FE="python3 fast-edit/fast_edit.py"# 第1段（~120行） cat > /tmp/part1.md << 'PART1' # 需求文档 ## 1. 项目概述 ...前 120 行... PART1# 第2段（~120行） cat > /tmp/part2.md << 'PART2' ## 3. 非功能需求 ...后续 120 行... PART2# 合并写入目标文件 cat /tmp/part1.md /tmp/part2.md > /tmp/combined.md $FE paste docs/REQUIREMENTS.md --stdin < /tmp/combined.mdrm -f /tmp/part*.md /tmp/combined*.md
每段控制在 120-160 行，heredoc 标记用单引号防止变量展开。分段写入临时文件，合并后通过 fast-edit 的 paste --stdin 一次性写入目标路径。
为什么不直接 cat > 目标文件？因为 fast-edit 还做了文件校验、编码处理、原子写入等保护。直接 cat 在多段追加时容易出现竞态条件。
◆ 在 Prompt 中嵌入写入指令
光有工具不够，还得让 AI "知道"怎么用。我在文档生成的 prompt 中直接嵌入了写入指令：
【文件写入 - 严格遵守】 ⚠️ 严禁使用 Write 工具（会卡在 pending） ⚠️ 严禁使用 cat <<'EOF' > file（超过 150 行会超时） ✅ 必须使用 fast-edit 分段写入
这段指令会自动追加到所有 ULW（Ultra-Long Write）模式的 prompt 末尾。AI 看到这个约束后，会自觉采用分段策略。
◆ 竞态条件的处理
分段写入引入了新问题：AI 的 SSE 文本回复可能比文件写入先结束。你的后端认为"AI 说完了"，去读文件——文件还没写完。
解决方案是"文件稳定性检测"：
# 等待文件大小连续 3 次检查不变（稳定 6 秒） for attempt in range(150): # 最多等 5 分钟 if os.path.isfile(doc_file_path): current_size = os.path.getsize(doc_file_path) if current_size == last_file_size and current_size > 0: stable_count += 1 if stable_count >= 3: # 稳定了，可以读取 break await asyncio.sleep(2)
文件大小连续 3 次检查（间隔 2 秒）没有变化，才认为写入完成。简单但有效。
◆◆ fast-edit 还能做什么？
除了解决「大文件写入」问题，fast-edit 在日常开发中也很实用：
批量替换：500 行文件改 3 处，传统 Edit 工具需要读-改-写三次（约 15 秒），fast-edit 的 batch 模式一次搞定（不到 0.1 秒）。
stdin 粘贴：用户在聊天框粘贴了一大段代码，fast-edit 的 paste --stdin 可以直接从管道接收并写入文件，不需要 AI 在输出中"复述"一遍（省 token）。
save-pasted：从 OpenCode 的内部存储中提取用户粘贴的超大文件，零 token 输出直接落盘。对于 200+ 行的粘贴内容，这个命令能节省大量 token 消耗。
◆◆ 实战效果
在 task-opencode 的设计工作流中，这套方案已经稳定运行：
文档类型典型行数分段数需求文档 REQUIREMENTS.md500-1000 行4-8 段架构设计 ARCHITECTURE.md800-1500 行6-12 段功能列表 FEATURES.md200-500 行2-4 段API 文档 + OpenAPI JSON500-800 行4-6 段
每次生成都走 ULW 模式 + fast-edit 分段写入，成功率从之前的"五五开"提升到了接近 100%。
◆◆ 写在最后
AI 生成长文档的写入问题，本质上是工具能力和任务需求之间的 gap。解决方案不复杂——分段、合并、校验——但关键在于把这些策略编码到 prompt 中，让 AI 自己学会正确的写入方式。
fast-edit 不是万能的，但它解决了一个很具体的痛点：让 AI 能可靠地写大文件。
如果你也在用 AI 做代码生成、文档生成之类的工作，遇到过写入截断的问题，可以试试类似的分段策略。工具链的"最后一公里"往往藏着最多的坑。
工具链的最后一公里，往往藏着最多的坑。
代码已开源：https://github.com/includewudi/fast-edit ，已安装的请更新到最新。
作者：极寒AI
页:
[1]