@@ -1,552 +0,0 @@
# Grill Me Results
Generated: 2026-10-05T07:11:32.355Z
## Plan
给我一个手机端个人助手的系统提示词
## Shared Understanding
目标：把矮人要塞（Dwarf Fortress）部署到本地（Windows 侧），并让一条自动化管道持续把游戏世界的历史写成中文连载故事，自动推送到自建 Gitea 公开仓库。
核心取舍：不做 AI 自动游玩（B），只做「世界史编年史」（A）——通过 worldgen 生成世界 + DFHack 导出 legends 历史数据，再由云端 LLM 把结构化历史写成战报体连载。原因：本机无独显（13G 内存 / Radeon 780M），跑不动本地模型；而 AI 操控游戏极其脆弱，被列为第二阶段目标。
三条链路：
1. Windows 侧（/mnt/c/Users/23518）：DF 53.16 免费版 + DFHack 53.16-r2 → 生成 Medium 世界 / 250 年历史 → 导出 legends 数据。
2. WSL2 Ubuntu 侧：Python 管道解析 legends → 建年表与人物索引 → 按事件链切片（每章 800–1500 字）→ 组 prompt（要塞编年史官口吻、战报体、自由演绎）→ 调 workbuddy 网关（cn:deepseek-v4-pro）→ 产出 Markdown 章 → 专名事实校验并标注可疑处。
3. Gitea（ ，
关键事实（已实测，无需再确认）：无任何 API key 环境变量；Pi 的 provider 是用户自建网关 workbuddy（ ， ； ；
## Questions and Answers
### 1. 矮人要塞本体跑在哪一侧？
**Recommended answer: ** Windows 侧跑 DF + WSL 侧做自动化（已有 Steam、原生 GPU 性能好；WSL 当故事工厂，经 /mnt/c 读存档）
**User answer: ** Windows 跑 DF，
**Status: ** resolved
**Notes: ** 已确认 Windows 有 Steam（但库里无 DF）、WSLg 可用；本机无独显，故写作环节必须离开本机推理。
### 2. 用哪个版本、怎么拿到？
**Recommended answer: ** Bay 12 免费 classic v50（免费且 DFHack 主线支持）
**User answer: ** Bay 12 免费 classic v50
**Status: ** resolved
**Notes: ** Windows 版免费 classic v50 + Windows 版 DFHack；无需购买 Steam 版。
### 3. 『不断产出故事』具体指哪种？
**Recommended answer: ** A 世界史编年史 + C 人玩机录（先保证持续有内容，B 当第二阶段）
**User answer: ** A 世界史编年史
**Status: ** resolved
**Notes: ** 只做 worldgen/legends 导出叙事，不做 AI 自动游玩。与 continuity 的『同一世界长期连载』结合后，产生一个待澄清矛盾：历史是有限的，写完后如何继续产出。
### 4. 产出节奏和章节长度？
**Recommended answer: ** 事件驱动，每章 800–1500 字
**User answer: ** 事件驱动，每章 800–1500 字
**Status: ** resolved
### 5. 谁来把游戏数据写成故事？
**Recommended answer: ** 云端 LLM API（
**User answer: ** 云端 LLM API
**Status: ** resolved
**Notes: ** 实测：DeepSeek/Moonshot/SiliconFlow 可达，openai.com 超时。
### 6. 若走云端 LLM，每月成本上限？
**Recommended answer: ** 20 元以内 / 月
**User answer: ** 不限，能跑通就行
**Status: ** resolved
**Notes: ** 成本不再是约束；模型选择自由度放宽，可用长上下文模型喂完整 legends 数据。
### 7. 故事最终发布到哪？
**Recommended answer: ** 先只落本地 git 仓库（Markdown），博客/Gitea 之后接
**User answer: ** 推到自建 Gitea（ ）
**Status: ** resolved
**Notes: ** 未选本地 git 仓库与博客，仅 Gitea；需澄清仓库名、可见性与推送认证（SSH 2222 端口）。
### 8. 世界观怎么延续？
**Recommended answer: ** 同一世界长期连载（人物家族仇恨跨章延续）
**User answer: ** 同一世界长期连载
**Status: ** resolved
**Notes: ** 与『只做 A』冲突：legends 历史有限，写完即断供，需第二轮定完结策略。
### 9. 什么时候跑？
**Recommended answer: ** 先手动一条命令，稳定后再加 cron
**User answer: ** 你帮我跑（自定义答案，未选任何选项）
**Status: ** resolved
**Notes: ** 含义待澄清：可能是『每次我说一声你就跑』或『你替我配好自动化并代跑』。真实约束：agent 无法在会话外自主持续运行，定时执行必须落在 WSL cron 或 Windows 任务计划上。
### 10. 允许我装系统依赖吗？
**Recommended answer: ** 可以，sudo apt 随便装
**User answer: ** 可以，sudo apt 随便装
**Status: ** resolved
**Notes: ** WSL 内可装 xvfb、CJK 字体、python 库；Windows 侧 DF+DFHack 仅需解压，不需管理员权限。
### 11. 这次做到哪一步？
**Recommended answer: ** 最小 demo：装好 + 跑出 1 章故事
**User answer: ** MVP + 定时自动化 + 已发布到某处
**Status: ** resolved
**Notes: ** 范围比推荐更大，需与 trigger 的澄清一起确定自动化落点。
### 12. 故事要不要配图？
**Recommended answer: ** 先不要，先把文字闭环跑通
**User answer: ** 纯文字
**Status: ** resolved
### 13. 输出语言？
**Recommended answer: ** 中文，专名保留英文
**User answer: ** 中文（专名保英文，如 Urist、Boatmurdered）
**Status: ** resolved
### 14. 故事引擎要不要搬到服务器 124.222.29.26 常驻？
**Recommended answer: ** 先本地，之后考虑搬服务器
**User answer: ** 先本地，之后考虑搬服务器
**Status: ** resolved
### 15. 这个「手机端个人助手」是 softwork1 项目里的助手，还是一个全新的独立助手？
**Recommended answer: ** 与 softwork1 项目无关的独立助手
**User answer: ** 与 softwork1 无关：只是我独立手机本地的助手
**Status: ** resolved
**Notes: ** 推翻了第一轮基于 softwork1/sw1-p3 代码事实建立的全部前提（daemon、appendSystemPrompt、memory/rules 注入等都不再适用）。
### 16. 提示词主要给哪类手机助手用？（推荐：云端大模型 App——能力完整、支持自定义系统提示词，兼容性最好）
**Recommended answer: ** 云端大模型 App（
**User answer: ** 云端大模型 App（
**Status: ** resolved
### 17. 平台范围？（推荐：通用——只写与 iOS/Android 无关的行为规则，以后换 App 也能用）
**Recommended answer: ** 通用，不绑定平台
**User answer: ** 只 Android
**Status: ** resolved
**Notes: ** 与推荐不同：仅面向 Android。
### 18. 这个助手有没有「干活」的能力（联网搜索、日历、发消息等）？（推荐：按无工具写——大多数手机 App 只有对话，宁可让它老实说做不到，也不要假装已执行）
**Recommended answer: ** 没有工具，只有纯对话
**User answer: ** 有工具调用（查网页、日历、笔记、发消息）
**Status: ** resolved
**Notes: ** 与推荐不同：助手确实有工具，提示词应包含工具使用规则而不是保守回避。
### 19. 你主要用它干什么？可多选（推荐：信息整理 + 写作润色 + 日程待办）
**Recommended answer: ** 信息整理与总结、写作与润色、日程待办与计划安排
**User answer: ** 信息整理与总结（长文、链接、聊天记录）；答疑与学习（技术问题、概念解释）；随手记与灵感整理
**Status: ** resolved
**Notes: ** 与推荐部分不同：不含写作润色与日程待办，含答疑学习与随手记。
### 20. 人格定位？（推荐：干练私人助理）
**Recommended answer: ** 干练私人助理（简洁、先结论后细节）
**User answer: ** 干练私人助理（简洁、先结论后细节）
**Status: ** resolved
### 21. 语言与称呼？（推荐：中文、称「Chen Yi」）
**Recommended answer: ** 中文，称呼 Chen Yi
**User answer: ** 中文，称呼 Chen Yi
**Status: ** resolved
### 22. 单条回复默认多长？（推荐：3–5 行结论 + 要点）
**Recommended answer: ** 3–
**User answer: ** 不限长度，完整回答
**Status: ** resolved
**Notes: ** 与推荐不同，且与「干练私人助理（简洁）」存在张力，已作为第三轮追问点。
### 23. 长回答要不要固定结构？（推荐：结论 / 依据 / 下一步 三段）
**Recommended answer: ** 固定三段：结论 / 依据 / 下一步
**User answer: ** 不固定（自定义填写，未选任何预设项）
**Status: ** resolved
### 24. 信息不足时怎么办？（推荐：先问一个最关键的问题）
**Recommended answer: ** 先问一个最关键的问题，等回答
**User answer: ** 直接给 2–
**Status: ** resolved
**Notes: ** 与推荐不同，且与「末尾不给下一步建议」存在边界模糊，已作为第三轮追问点。
### 25. 回答末尾要不要带「下一步建议」？（推荐：最多一条）
**Recommended answer: ** 最多给一条下一步建议
**User answer: ** 不给建议，答完即止
**Status: ** resolved
**Notes: ** 与「信息不足时给 2–3 个方案」有边界冲突，第三轮澄清。
### 26. 语气约束？（推荐：禁 emoji、禁客套套话）
**Recommended answer: ** 禁 emoji、禁客套套话，直接给结论
**User answer: ** 允许幽默和闲聊
**Status: ** resolved
**Notes: ** 与推荐差异较大，且与「干练私人助理」人格、用途清单（未选闲聊）有点张力，第三轮问幽默程度。
### 27. 要不要明确「不许装能力」？（推荐：要）
**Recommended answer: ** 明确写：不假装执行任何手机操作或查询，做不到就直说
**User answer: ** 只写「不确定就说明」，不专门限制
**Status: ** resolved
**Notes: ** 与「有工具调用」搭配合理，但与推荐不同；有工具时假装风险较低。
### 28. 隐私口径？（推荐：只用你主动给的信息，不索要敏感信息，不假装记得历史对话）
**Recommended answer: ** 只用对话里主动给的信息，不索要敏感信息，不假装记得历史对话
**User answer: ** 需要时可以直接追问个人信息
**Status: ** resolved
**Notes: ** 与推荐不同；因另选了「App 有跨会话记忆」，持久化敏感信息的分寸需在第三轮定。
### 29. 手机 App 一般没有跨会话记忆，怎么处理？（推荐：长任务结尾给一段可复制的上下文摘要）
**Recommended answer: ** 长任务结尾给一段可复制的「上下文摘要」
**User answer: ** 这个有（自定义填写：App 有跨会话记忆）
**Status: ** resolved
**Notes: ** 推翻推荐前提：有持久记忆，摘要方案不再必要；改为追问记忆写入机制。
### 30. 讲解深度？（推荐：按计算机专业学生，直接讲机制与结论）
**Recommended answer: ** 按技术用户，直接讲机制/结论，不科普
**User answer: ** 适度解释术语和取舍
**Status: ** resolved
### 31. 提示词本身体量？（推荐：≤1 页 400–800 字）
**Recommended answer: ** 精炼，≤1 页（约 400–800 字）
**User answer: ** 精炼，≤1 页（约 400–800 字）
**Status: ** resolved
### 32. 要不要在提示词里放示例？（推荐：放 1–2 个短范例）
**Recommended answer: ** 放 1–
**User answer: ** 只写规则，不放例子
**Status: ** resolved
**Notes: ** 与推荐不同：不带范例，提示词更短。
### 33. 交付验收？（推荐：落一份 md + 聊天贴全文）
**Recommended answer: ** md 文件落盘 + 聊天贴全文
**User answer: ** md 文件落盘 + 聊天贴全文
**Status: ** resolved
### 34. 世界史是有限的历史——同一个世界写到史末之后怎么办？
**Recommended answer: ** 按卷连载，写完宣布该世界史完结，再用同一叙述者人设开新世界新一卷
**User answer: ** 一部史分卷连载，完结后换新世界开新卷
**Status: ** resolved
**Notes: ** 第二轮把上一轮『只做 A + 长期连载』的断供矛盾解开了：一个世界分卷连载，完结后换新世界开新卷。
### 35. 『你帮我跑』具体怎么落地？
**Recommended answer: ** 先手动跑通，稳定后再开定时
**User answer: ** 先手动跑通，稳定后再开定时
**Status: ** resolved
**Notes: ** 与 deliverable=MVP+定时自动化 不矛盾：定时任务要搭但手动验证后才启用。
### 36. Gitea 上的仓库怎么建？
**Recommended answer: ** 新建私有仓库 dwarf-fortress-annals，用 SSH key 自动推
**User answer: ** 新建公开仓库
**Status: ** resolved
**Notes: ** 与 publish_target=Gitea 一致；公开仓库意味着措辞和事实错误会直接对外可见。
### 37. 生成好的一章要不要先给你过目？
**Recommended answer: ** 先生成到本地待审，我点头再推
**User answer: ** 自动直接推，我事后自己改
**Status: ** resolved
**Notes: ** 与推荐相反，且仓库为公开：LLM 幻觉会直接进公开『正史』。已列入风险。
### 38. 一章切多大一段历史？
**Recommended answer: ** 一个世纪或一条完整事件链
**User answer: ** 混合
**Status: ** resolved
**Notes: ** 与上一轮 events-driven、每章 800–
### 39. 世界生成参数倾向？
**Recommended answer: ** Medium 世界 + 250 年
**User answer: ** Medium 世界 + 250 年
**Status: ** resolved
**Notes: ** 确定后单次 worldgen 即可支撑数十章素材。
### 40. 用哪家云端 LLM、key 怎么准备？
**Recommended answer: ** DeepSeek（便宜且网络可达），key 由你自己申请后写入 WSL 环境变量
**User answer: ** 用你的（自定义答案）
**Status: ** resolved
**Notes: ** 自定义答案『用你的』语义不明：我没有任何可用的 API 密钥，且不能向你索要密钥内容。需第三轮澄清落地方式。
### 41. Windows 侧的 DF + DFHack 由谁装？
**Recommended answer: ** 我经 /mnt/c 下载解压放好，你只需最后点开确认
**User answer: ** 你（agent）下载解压到 /mnt/c 下
**Status: ** resolved
**Notes: ** 需确认 Bay 12 下载链路与 Windows 用户目录名（/mnt/c/Users 下有 23518、WsiAccount 等）。
### 42. 叙述口吻用哪种？
**Recommended answer: ** 史官编年体（冷静第三人称）
**User answer: ** 战报体（诙谐吐槽，像 Boatmurdered）
**Status: ** resolved
**Notes: ** 口语口吻与『历史数据→叙事』的匹配度低于编年体，但趣味性更高；牵出一新问题：战报体的『我』是谁（因为本方案不玩，没有玩家视角）。
### 43. 『用你的』具体指什么？
**Recommended answer: ** 就由我（agent）当写作引擎 / 或你自己导出 key 给脚本
**User answer: ** 用 Pi 里已配好的那家（你只需把 key 再导一份给脚本）
**Status: ** resolved
**Notes: ** 用户选择复用 Pi 已配好的 provider，需确认是哪一家/env 变量名；我不会读取 auth.json 内容。
### 44. 推送到 Gitea 用哪种认证？
**Recommended answer: ** 生成新密钥对 + 你贴公钥
**User answer: ** 直接复用已有的 ~/.ssh/id_ed25519
**Status: ** resolved
**Notes: ** 待验证：该公钥是否已在 Gitea 账号注册（已测 2222 端口开放）。
### 45. 战报体里的『我』是谁？
**Recommended answer: ** 要塞里的编年史官（在场记录 + 吐槽）
**User answer: ** 要塞里的编年史官（在场记录 + 吐槽）
**Status: ** resolved
**Notes: ** 与自由演绎 + 战报体相洽。
### 46. 公开仓库里放什么？
**Recommended answer: ** 成品 + 迷你年表/人物索引
**User answer: ** 成品 + 迷你年表/人物索引
**Status: ** resolved
**Notes: ** 年表/索引同时充当事实核对的参考面。
### 47. 战报体允许多少文学加工？
**Recommended answer: ** 自由演绎 + 章末附史料注
**User answer: ** 自由演绎：对白、心理、吐槽都写
**Status: ** resolved
**Notes: ** 与自动专名校验存在张力：校验只能拦住『凭空的人名地名』，拦不住编造的对白与心理活动，但用户已接受此代价。
### 48. 既然自动直推 + 公开仓库，要不要自动事实校验？
**Recommended answer: ** 要：自动比对专名，可疑处标注
**User answer: ** 要：自动比对专名是否都出现在 legends 数据里，可疑处标注
**Status: ** resolved
### 49. 这次做到什么程度算完成？
**Recommended answer: ** 第 2、3 章也能稳定产出并自动推上去
**User answer: ** DF 能跑 + 第 1 章出现在 Gitea
**Status: ** resolved
**Notes: ** 本次验收比 deliverable=mvp_plus 窄：定时任务暂不纳入验收，与 automation_owner=先手动跑通一致。
### 50. 用网关里的哪个模型写故事？
**Recommended answer: ** cn:deepseek-v4-pro
**User answer: ** cn:deepseek-v4-pro（推荐）
**Status: ** resolved
**Notes: ** 已查明 Pi 配置的 provider 为 workbuddy（ ，
### 51. API key 怎么交给脚本？
**Recommended answer: ** 脚本运行时自读 ~/.pi/agent/auth.json 的 workbuddy.key
**User answer: ** 脚本运行时自己读 ~/.pi/agent/auth.json 里的 workbuddy.key（推荐）
**Status: ** resolved
**Notes: ** auth.json 结构为 { workbuddy: { type, key } }；脚本运行时读取，我不读不打印内容。
## Agreed Decisions
- 部署形态：Windows 侧跑 DF，
- 版本与获取：Bay 12 免费版（当前实为 53.16， ）
- 安装执行：由 agent 经 /mnt/c 下载解压到 Windows 用户目录（免管理员权限），用户只需最后点开确认游戏能跑
- 故事形态：只做 A 世界史编年史（worldgen + legends 导出 + LLM 叙事），不做 AI 自动游玩；B 方案列为第二阶段
- 连载完结策略：一个世界分卷连载，写完全部历史即宣布该世界史完结，再生成新世界开新卷，用同一套叙述者人设维持系列感
- 章节切分：混合式——有重大事件就写事件链，太平年份合并成章；每章 800–1500 字，事件驱动而非日更
- 世界参数：Medium 世界 + 250 年历史
- 叙事引擎：复用 Pi 里已配好的 provider，即用户自建网关 workbuddy（ ，
- 写作模型：固定使用 cn:deepseek-v4-pro（
- API key 交付：脚本运行时自读 ~/.pi/agent/auth.json 中的 workbuddy.key；不额外落明文副本，agent 只写读取代码、不读不打印内容
- 叙述者身份：要塞里的编年史官（在场记录 + 吐槽），不用现代玩家视角，也不用单个人物第一人称日记
- 叙述口吻：战报体（诙谐吐槽，类比经典 Boatmurdered）
- 演绎边界：自由演绎——对白、心理活动、吐槽都可写（代价是读者无法区分史料与文学）
- 自动事实校验：要。生成后自动比对专名是否都出现在 legends 数据中，可疑处标注（不阻断推送）
- 发布去向：只推自建 Gitea（
- Gitea 仓库：新建公开仓库 dwarf-fortress-annals
- 推送认证：直接复用现有 ~/.ssh/id_ed25519（已验证在 Gitea 注册为 chendy-ubuntu-wsl / gitadmin），无需新建密钥或 token
- 仓库内容：成品 Markdown + 迷你年表/人物索引；不入库原始 legends 数据与存档
- 推送门槛：不做人工审核，自动直接推送到 Gitea，用户事后自行修改
- 输出语言：中文，专有名词保留英文（如 Urist、Boatmurdered）
- 配图：纯文字，不做地图/ASCII 渲染配图
- 系统依赖：允许 sudo apt 任意安装 WSL 侧依赖
- 触发方式：先手动一条命令跑通，稳定后再开 WSL cron 定时；当前不启用常驻 daemon 与开机自启
- 运行位置：先全部在本地，后续再考虑搬到服务器 124.222.29.26
- 本次验收标准：DF 能在 Windows 侧跑起来 + 第 1 章中文故事出现在 Gitea 公开仓库（定时任务不纳入本轮验收）
## Open Risks
- 自动直推 + 公开仓库：LLM 幻觉会直接进入对外可见的「正史」。用户接受事后自行修改，但专名校验只能拦住凭空出现的人名地名，拦不住编造的对白与心理活动（自由演绎已明确放开）——这类错误没有任何自动防线
- 唯一外部依赖是用户自建网关 workbuddy（
- cron 定时依赖 WSL 常驻：Windows 关机、WSL 闲置回收都会让产出静默断供；无人值守时失败不易被发现
- 战报体 + 固定「要塞编年史官」人设需要跨章长期一致，仅靠 prompt 约束，长连载下口吻与设定可能漂移（跨章设定漂移检查未列入本次范围）
- 版本必须严格配对：DF 53.16 只能配 DFHack 53.16-r2；
- legends 导出的自动化程度尚未实测：53.x 上的导出入口（游戏内 UI / DFHack 命令）能否完全脚本化、免手动点击，需要在实施第一步验证；若必须人工点击，则「无人值守」目标需降级
- WSL2 为 NAT 网络（网关 172.31.48.1），WSL 与 Windows 侧进程的实时通信（若将来需要 DFHack RPC）需额外配置；本方案走文件交换可绕开，但第二阶段 B 方案会直面此问题
- Windows 用户目录疑似 /mnt/c/Users/23518（另有 WsiAccount），实施时需确认哪个是实际登录账户
- 服务器迁移路径已被承认但未设计：服务器无图形界面，未来最多只能承载「世界史生成 + 叙事 + 发布」，游玩相关环节无法搬移
## Next Decision Needed
无待决项。下一步是实施：先验证 legends 导出的可脚本化程度与 Windows 实际用户目录，再搭 WSL 管道，最后以「DF 能跑 + 第 1 章推到 Gitea」验收。
Chen Yi