企业官网建设流程全解析

Kimi Code CLI 功能冒烟测试 Prompt 模板：单轮/多轮决策与五段式验证范式

【免费下载链接】kimi-cliKimi Code CLI is your next CLI agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kimi-cli

在 Kimi Code CLI 这类以 Agent 为核心的开源命令行工具中，为新增或变更功能做端到端冒烟测试，最大的难点不是跑命令，而是如何写出可复用、可追溯、不依赖模型"记忆幻觉"的测试 prompt。本文围绕仓库内.agents/skills/feature-smoke-test/references/prompt-patterns.md提供的 Prompt 模板体系展开，讲解单轮/多轮的选择标准、占位变量、探索—执行—观察—复盘—兼容性校验五类模板的完整用法，并结合feature-smoke-testSkill 的非交互运行方式与context.jsonl/wire.jsonl等 session 产物，给出可直接落地的冒烟测试实操方案。读完本文，你将能独立为 Kimi Code CLI 的任何功能设计出结构化、证据可查的多轮冒烟测试流程。

一、模板定位：脚手架而非固定答案

Prompt 模板的定位是脚手架（scaffold）：它们不替你决定测试内容，而是约束 Agent 的行为边界，避免测试过程中出现"假设旧接口仍然正确""一次性长回复盲写""把观察与执行混在一起"等典型失控。原始模板文档明确要求：运行前替换占位符，且不得信任过时的文档、旧 prompt 或旧 tool 名称——一切以当前代码中的真实对外接口为准。

这一设计理念与 SKILL.md 中"先读事实来源（面向用户的文档、changelog、agent/tool prompt、实现层入口、已有测试）"的步骤一一对应：模板负责流程，事实来源负责内容。

二、第一步决策：单轮还是多轮

模板文档给出的决策规则是：满足以下任一条件时使用多轮：

• 功能有状态（session、后台任务、审批状态等）
• 功能依赖时序或并发
• 功能需要审批、清理或恢复
• session 产物本身是证据的一部分
• 工具接口可能近期发生过变化

而仅对无状态的窄范围检查使用单轮。

这条规则在 Skill 中被进一步强调为默认策略："如果功能涉及状态、异步、审批流或时序敏感逻辑，默认认为单条 prompt 不够"；并且多轮测试时"每一轮单独调用 CLI，在两轮之间检查上一轮的输出和产物，再决定下一轮的 prompt"，不要把多轮 prompt 一次性塞进 stdin——那是盲写，无法根据上一轮结果调整（见 SKILL.md）。

判断要点：问自己"这一轮跑完，我是否需要根据它的产物决定下一轮做什么？"需要——就是多轮；不需要——单轮即可。

三、起草前的变量清单

模板文档要求在起草 prompt 前填写以下 8 个字段。这些占位符贯穿所有模板，务必先想清楚再动手：

其中<session_dir>的定位有明确的仓库依据：Session.create会把context.jsonl写入session_dir / "context.jsonl"，并把wire.jsonl以WireFile(path=session_dir / "wire.jsonl")的形式挂在 Session 上（见 src/kimi_cli/session.py），而session_dir位于 work-dir 对应的sessions/命名空间下。

四、五段式 Prompt 模板详解

以下五个模板是prompt-patterns.md的绝对核心，逐条继承并附使用说明。占位符必须替换后才能运行。

4.1 探索 prompt（Explore）：先复述真实接口

我要验证 <feature>。 先阅读这些文件并只总结当前真实对外接口，不要假设旧文档、旧 prompt 或旧 tool 名称仍然正确： <source_paths> 然后给我一个最小 smoke test 计划，只包含： 1. happy path 2. 一个边界/异常场景 3. 一个清理、恢复或中断场景 每个场景都写清楚目标、预期信号和要检查的产物。

使用说明：这一轮的目的是"事实对齐"——让 Agent 先读源码/文档，输出当前真实接口与最小三场景计划。它天然与 SKILL.md 的"三个场景默认覆盖"（正常路径 / 边界条件、非法输入或容量极限 / 中断、重试、清理或恢复）一致。如果 Agent 在此轮复述出与仓库不一致的接口名，应立即纠正，不要带病进入执行轮。

4.2 执行 prompt（Execute）：一轮只执行一个场景

在当前 session 里只执行这个场景：<goal> 约束： <constraints> 执行前先复述你将使用的工具或命令。执行时记录关键 task id、输出片段、文件路径和任何需要后续复盘的标识符。不要扩展到其他场景。

使用说明：执行轮强制"先复述再执行"，这是让 Agent 的行动可预测的关键机制；"不要扩展到其他场景"用于防止 Agent 在测试中顺手"帮忙"做了别的操作（例如顺便改配置、跑额外命令），污染证据。关键标识符（task id、审批 id、输出路径）必须记录，因为它们是复盘轮的索引。

4.3 观察 prompt（Observe）：只读不跑

现在不要继续跑新的测试。 只读取并总结这次运行已经产生的状态和文件： <artifact_paths> 请明确指出哪些证据支持了预期，哪些证据反驳了预期，哪些地方仍然不确定。

使用说明：观察轮把"读取证据"与"继续测试"硬性分离。模板要求输出三分类结论——支持预期的证据 / 反驳预期的证据 / 仍不确定的点。这与 SKILL.md 汇报环节的"已确认 / 与预期不符 / 仍有歧义"三分法完全同构，是避免"仅凭 assistant 最终文本推断正确性"的手段：运行时文件和工具结果才是事实来源（见 SKILL.md）。

4.4 复盘 prompt（Retrospective）：从 session 产物回溯全流程

请根据这个 session 目录复盘整个 smoke test： <session_dir> 重点阅读 context.jsonl、wire.jsonl 和相关运行产物。输出： 1. 实际执行流程 2. 关键 tool 调用与结果 3. 与预期不一致的点 4. 最小复现步骤

使用说明：复盘轮是证据链的最终落点。context.jsonl记录会话上下文（各 role 的消息、tool_calls、usage 等），wire.jsonl记录 Wire 协议层的结构化事件流。两者在仓库中的实现值得注意：

• context.jsonl在Session.create中创建，若已存在会被截断重建（src/kimi_cli/session.py）；
• wire.jsonl由WireFile管理，首行写入带protocol_version的 metadata 头，后续每行是一条WireMessageRecord（timestamp + WireMessageEnvelope）（src/kimi_cli/wire/file.py）。

wire 事件类型覆盖TurnBegin、StepBegin、ContentPart、ToolCall、ApprovalRequest、StatusUpdate等（见 src/kimi_cli/wire/types.py），因此复盘轮不仅能还原"Agent 说了什么"，还能还原"每一步调用了哪个工具、审批流如何走、上下文 token 如何变化"——这正是"最小复现步骤"的素材来源。

4.5 兼容性校验 prompt（Compatibility Check）：防接口幻觉

在运行 smoke test 之前，先从提供的文档或代码中复述当前真实可用的工具及其准确名称。不要臆造旧版工具名。如果任务涉及状态或时序，将工作拆分为多轮而非一次性长回复。

使用说明：这是一个前置护栏，通常在探索轮之前或与探索轮合并使用。Kimi Code CLI 的 tool 集合在持续演进（例如文件工具、shell 工具、plan 工具的 prompt 均在src/kimi_cli/tools/下有各自定义），旧示例中的工具名可能已经失效。此模板强制 Agent"从当前文档或代码复述工具名"，从源头杜绝幻觉接口。

五、模板落地：结合非交互模式的完整冒烟流程

模板只有配合正确的运行方式才有意义。feature-smoke-testSkill 给出了一套与上述模板严丝合缝的执行协议：

5.1 会话隔离

SMOKE_DIR="$(mktemp -d /tmp/kimi-smoke-XXXXXX)"

使用/tmp下的一次性目录作为--work-dir。CLI 的 session 路径由~/.kimi/sessions/<md5(work_dir)>/决定，不同的 work-dir 自动产生独立 session 命名空间，不会污染正常项目的 session（SKILL.md）。如果功能会编辑文件，绝不要用活跃仓库作为 work-dir。

5.2 默认执行方式

uv run python -m kimi_cli.cli \ --print \ --prompt "你的测试 prompt" \ --work-dir "$SMOKE_DIR" echo "exit_code=$?"

--print是 print 模式（非交互），其 CLI 定义为"auto-dismisses AskUserQuestion and auto-approves tool calls for this invocation"（src/kimi_cli/cli/init.py），等价于自动启用--yolo（--yolo/--yes/-y/--auto-approve，见同文件 L189-L198），适合无人值守冒烟。执行后必须先检查退出码：非零表示 CLI 本身崩溃或超时，应优先排查进程级错误，再看 session 产物。

5.3 备选执行模式

注意--input-format、--output-format、--final-message-only都要求配合--print使用，否则 CLI 会报参数错误（src/kimi_cli/cli/init.py）。

5.4 检查 session 产物

运行后按复盘模板检查：

• ~/.kimi/sessions/.../context.jsonl
• ~/.kimi/sessions/.../wire.jsonl
• 功能创建的 session 级文件

仓库提供了定位工具：

uv run python .agents/skills/feature-smoke-test/scripts/inspect_session.py --share-dir ~/.kimi

inspect_session.py 会自动定位最新 session，汇总文件清单、context.jsonl（按 role 统计 + 尾部记录摘要，assistant 记录会列出工具名）、wire.jsonl（按消息类型统计，含StepBegin/ContentPart/ToolCall/ApprovalRequest等摘要）以及后台任务（tasks/下的 spec/runtime/control/consumer 与 output.log）。脚本退出码 0 = 正常汇总，1 = session 目录缺失或无法解析。

如果功能会创建后台任务、通知或附属文件，直接检查这些文件，不要只依赖模型摘要。

六、模板的"刻意执行"纪律与汇报规范

最后，模板体系背后有一条贯穿性纪律（SKILL.md）：执行过程中维护运行日志，记录完整 prompt、关键工具调用、task id/输出路径/审批 id、时序敏感时的时间戳——不要仅凭 assistant 最终文本推断正确性。

汇报时把结果分为三类：已确认的行为 /与预期不符的行为 /仍有歧义、需要更确定性复现的行为。对每个 bug 或回归，记录触发它的 prompt、精确 session 路径、证明它的产物路径、可推导的最小复现步骤。

当发现与预期不符时，模板工作流并不止于报告：Skill 建议对每个问题同时启动多个独立探查方向（从入口沿调用链追踪、检查输入数据各阶段变化、检查持久化状态一致性、运行相关单元/集成测试），每条方向独立汇报"方向与范围、发现的事实（附文件路径和行号）、结论（已定位根因 / 已排除 / 需进一步调查）"，最终综合输出根因、证据链、修复建议与回归风险。

七、小结

prompt-patterns.md提供的是把冒烟测试从"随性对话"升级为"可复现实验"的模板体系：先按状态/时序/审批/产物/接口变化判定单多轮，再填好 8 个变量，然后依次走探索、执行、观察、复盘、兼容性校验五段流程，最后结合--print非交互模式、--work-dir隔离与context.jsonl/wire.jsonl产物完成证据闭环。这套方法不依赖任何特定模型的能力，只依赖流程约束与产物事实，可稳定复用于 Kimi Code CLI 后续每一个新功能的回归验证。

• 模板原文：references/prompt-patterns.md
• Skill 完整流程：SKILL.md
• session 产物检查脚本：scripts/inspect_session.py
• 产物落盘实现：src/kimi_cli/session.py、src/kimi_cli/wire/file.py

【免费下载链接】kimi-cliKimi Code CLI is your next CLI agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kimi-cli