# 完美的提示词 **Repository Path**: x-itg/perfect-prompt ## Basic Information - **Project Name**: 完美的提示词 - **Description**: 我所追求的【完美提示词】和【工程知识中枢】让您的AI发挥极致的交付能力。嵌入式控制算法 — 保真仿真闭环启动手册（Agent 版） - **Primary Language**: Unknown - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2026-10-01 - **Last Updated**: 2026-10-11 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # 嵌入式控制算法 — 保真仿真闭环启动手册（Agent 版） > 适用于任何控制算法（PID / 状态机 / 滤波器 / 自适应 / 模糊 / 观测器）。 > 本文档面向 agent，可直接执行。遇到不明确处停下问人，不要自己补假设。 --- ## 0. 阅读本文档的规则 1. **先读第 1 节自检锚点。** 锚点不全，停止。 2. **本文档用"必须/禁止"表达硬约束。** 违反即体系失效。 3. **不要在本手册之外扩展流程。** 需要扩展时先问人。 --- ## 1. 前置锚点（人必须先给） 启动前必须齐备。缺任何一项，列出缺口，**停下等补齐**。 | 锚点 | 内容 | 缺失后果 | |---|---|---| | 真源 | 算法源代码文件路径（.c/.cpp/.h） | 无法建桩 | | 编译环境 | 编译器版本、libm 来源、目标架构 | 保真闸门假失败 | | 物理模型参数 | 被控对象的时间常数、延时、增益、饱和值、已知非线性 | 场景测试无意义 | | 判据阈值 | 每个测试场景的通过标准（数值 + 单位） | 无法判 PASS/FAIL | | 硬件约束 | 采样周期、执行器限幅、传感器量程 | 参数范围无依据 | | 版本控制 | git 仓库已初始化，有 clean baseline | 无法回退 | **禁止**在锚点不全时"先搭骨架"。没有锚点的闭环会让你自信地错。 --- ## 2. 通用架构（不依赖算法类型） ``` ┌─────────────────────────────────────────┐ │ 真源算法（C/C++） │ │ 最终要烧进硬件的那份代码 │ └─────────────────────────────────────────┘ │ │ │ ①同一份源码 │ ②手工移植 │ 换桩头文件 │ 逐行等价 ↓ ↓ ┌───────────────┐ ┌───────────────┐ │ 测试桩（C） │ │ Python 镜像 │ │ PC 可编译 │ │ PC 可仿真 │ └───────────────┘ └───────────────┘ │ │ └────── ③保真闸门 ─────────┘ 逐周期逐字段比对 （浮点按位模式） │ ↓ ┌─────────────────────┐ │ 闭环仿真 + 场景测试 │ │ （模型 + 判据） │ └─────────────────────┘ │ ↓ 测试报告（PASS/FAIL） │ ┌─────────┴─────────┐ ↓ ↓ 有 FAIL 全 PASS │ │ ↓ ↓ 归因 → 改真源 保持 + 下一功能 同步两镜像 │ └──── 回到保真闸门 ``` **传递性原理**： ``` 真源 ≡ 测试桩 （同一份源码，换编译环境） 测试桩 ≡ Python （保真闸门逐位通过） ───────────────────────────────── ∴ 真源 ≡ Python （Python 上的结论对真源有效） ``` **传递性的边界**：仅在相同指令集 + 相同 libm 下成立。跨平台需重新建基准。 --- ## 3. 启动顺序（不可跳） ### Step 1 — 建桩，让真源在 PC 上跑 - 用桩头文件替换所有硬件依赖（寄存器、外设、RTOS API） - 关闭依赖硬件的条件编译宏 - 桩接受输入序列，每周期输出全状态 **必须**：同一份真源文件，不重写。 **验证**：桩能编译并跑通一个最小输入序列。 ### Step 2 — 消除 libm / 工具链差异 - 若算法用超越函数（log/exp/sin/sqrt），**必须**确保 C 桩与 Python 用同一个实现 - 方法：用同一编译器编译 shim 库，Python 通过 ctypes 调用 - **禁止**：让 Python 用系统 CRT、C 桩用另一套 **不做这步，保真闸门会以假失败告终。** ### Step 3 — 写 Python 镜像 硬性规则： - 浮点全用单精度（如 `numpy.float32`） - 整数按 C 规则截断（u8/u16/u32 饱和） - **运算顺序严格照抄**——浮点加减不满足结合律 - **禁止手抄宏值**，建 `sync_from_firmware()` 从真源解析 `#define` - 每个状态字段与真源一一对应 ### Step 4 — 建保真闸门 - 同一输入序列喂两程序 - 逐字段比对，浮点按 IEEE754 位模式 - 任一字段不一致 → 报错，**不通过** **验证**：闸门全序列通过，Step 3 才算完成。 ### Step 5 — 建被控对象模型 最少包含： - 一阶惯性 / 积分特性 - 纯延时（输入侧 + 反馈侧） - 饱和 / 变化率限制 - 已知非线性（死区、回滞、塌陷、关断） - 噪声（抖动、量化、漂移） **每个参数必须有出处**。外推值必须显式标注"未实测"。 ### Step 6 — 写场景测试 一个场景 = 一个物理/行为问题 + 一个判据。 ```python def test_<现象名>(): sim = 构造闭环(...) sim.run(时长, 输入) m = sim.metrics(输入) assert m["<指标>"] <阈值>, f"<详情>" ``` **判据从规格/标准/用户来。定不了就停下问人。** --- ## 4. 每轮迭代循环（固定动作） ``` ① 跑全场景测试 → 报告 ② 有 FAIL？ ├─ 是 → 归因： │ ├─ 算法层 → 改真源 + 同步 Python │ ├─ 模型层 → 先确认是模型问题（用真机数据佐证）→ 改模型 │ └─ 判据层 → 停下，问人（判据是锚点，不是自由变量） └─ 否 → 下一功能 ③ 保真闸门必须全通过 ├─ 过 → 继续 └─ 不过 → Python 没同步 → 修，别绕 ④ 全场景重跑（确认无回归） ⑤ git commit（每轮一个） ``` **三条纪律**： 1. 改真源必同步 Python。不同步 = 体系失效。 2. 保真闸门不过，禁止跑场景。先在闸门里过。 3. 禁止改判据让测试过。判据是外部锚点。 --- ## 5. 红线（违反即失败） | 禁止项 | 后果 | |---|---| | 改 Python 不改真源 | 保真链断，所有结论失效 | | 改判据让测试过 | 自欺，体系失去意义 | | 跳过保真闸门跑场景 | 无验证的结论 = 赌博 | | 手抄宏值当配置 | 会漂移，必须自动同步 | | 无真机数据就"优化"模型参数 | 模型是锚点，不是自由变量 | | 拿保守模型当真实值 | 集总/简化模型给的是界，不是真值 | | 只跑确定性单轨迹就宣称"稳" | 必须做 MC，看分布不看单点 | | 单变量扫参后直接定值 | 参数耦合必须用因子设计 | --- ## 6. 每轮检查清单 - [ ] 保真闸门全部序列通过 - [ ] 场景测试全 PASS - [ ] 无新增 RISK - [ ] 真源与 Python 的宏值一致（自动同步，非手抄） - [ ] commit 说明包含"改什么 / 为什么 / 影响范围" - [ ] 扫参脚本与结果入库 - [ ] 若引入新参数：登记进参数表（面板/固件/镜像三处同步） --- ## 7. 循环的边界 **能解决**： - 算法逻辑 - 参数整定 - 场景覆盖 - 极限工况 **不能解决**： - 模型偏离真实硬件 - 判据不符合当前需求 - 外部约束（温度、批次、EMI、器件老化） **定期对账**（按里程碑，非每轮）： - 用真机数据校准被控对象模型 - 审视判据是否仍符合当前需求 - 工具链变更后重建 libm shim - 跨平台移植时重新基准保真闸门 --- ## 8. 常见失败模式 | 症状 | 原因 | 处理 | |---|---|---| | 保真闸门 cycle 0 挂 | 取整方式 / 满量程 / 精度不一致 | 逐字段排查截断点 | | 保真闸门若干周期后漂移 | libm 不同源 | 重建 shim | | 场景过但真机不对 | 模型偏离真实 | 校准模型，不改算法 | | 改一处 PASS、改另一处挂 | 参数耦合 | 因子设计扫参 | | 确定性 / MC 结果差很多 | 噪声施加方式不同 | 查单点注入 vs 逐台注入 | | 全 PASS 但用户不满意 | 判据不反映真实需求 | 停下，重审判据 | --- ## 9. 启动触发词 收到"开始新项目"指令时： 1. 检查第 1 节锚点 → 不全则列出缺口等补齐 2. 按第 2 节建目录 3. 从第 3 节 Step 1 开始 4. 每轮循环按第 4 节执行 5. 每轮结束跑第 6 节清单 **不需要人再解释一遍流程。** --- ## 10. 一句话总纲 > **先建保真闸门，再写功能。改真源必同步镜像。判据是锚点，模型是锚点，只有算法和参数是自由变量。** --- ## 附：本手册的适用范围 | 适用 | 不适用 | |---|---| | 有明确真源的单体算法 | 无源码的闭源库 | | PC 可编译（有桩化方案） | 依赖不可替换的硬件时序 | | 被控对象可离线建模 | 强耦合多物理场（电磁+热+机械） | | 判据可数值化 | 主观评价类需求 | | 单周期可独立验证 | 长时间统计特性（需真机长跑） | **不适用场景**：直接上真机试，别浪费时间在仿真上。 --- --- # 工具源码即方法论底座的 AGENT 工作流 > **真目标是"从固化了套路的工具源码出发，让 Agent 去完善目标工程"；但它不可直接操作，于是我们拿「提示词生成」与「知识管理挖掘」当代理目标——可操作、可验证、可自举，它们跑通了，真目标自然浮现。** 本仓库不是先做一个工具，而是先定一个**真目标**，再为它选一组**代理目标（proxy goal / 间接战略）**： - **真目标（深层）**：从固化了方法论套路的工具源码出发，交给 Agent，让它在目标工程里自主把项目改得更完善。 - **为什么不直接瞄它**：它**不可操作**（你没法直接"完善工程"，只能做具体动作）、**不可衡量**（"完善"到哪算完？没有判据）、**不可自举**（没有具体动作就没有可回流的经验）——直接瞄会陷入瘫痪或自嗨。 - **代理目标（表层）**：把真目标翻译成两个可操作的具体动作——**生成提示词**（把套路写成 Agent 可执行的指令）、**管理知识**（把目标工程里的经验锚定、固化、回流）。 代理目标不是妥协，是真目标的**可操作形式**；两者同构：表层达成的过程，就是深层实现的过程。间接战略的本质——**把注意力放在可控的具体动作上，让抽象目标成为这些动作的副产品。直接瞄大目标的人往往到不了；瞄小动作的人，大目标自己来了。** > 详细展开版（安装运行、目录结构、全部模块、数据流、边界与自举证明）见 [`prompt_builder_studio/README.md`](prompt_builder_studio/README.md)。 ## 工作方式：双目录分离 我们采用双目录分离架构，把方法论本身做成可被 Agent 读取、可随经验生长的知识底座： - **工具源码文件夹（弹性方法论 · 知识底座）**：Agent 首先加载本工具源码，读取其中固化的方法论、模块逻辑、工程规范、测试规则——它是一套带弹性的方法，而非死板步骤； - **目标工程文件夹（业务载体）**：Agent 带着这套方法进入目标工程，根据现场情况自主解读、落地，完成你指定的工程目标； - **经验回流**：遇到新场景产生的新经验，回流更新工具侧知识库，反过来细化、补全原本模糊的方法论，让整体系慢慢变清晰。 > 本质：工具源码 = Agent 的知识底座与能力范本；目标工程 = 待处理的业务载体。知识与待修改代码物理隔离，互不污染；方法论可弹性解读、可沉淀、可迭代、可复用，一套底座跑多个项目。 --- ## 一、提示词工坊（代理目标一 · 把套路落成可执行的提示词） 多会话、引导式地生成超长自主 Agent 提示词：分阶段问卷 + 问题卡片 + 实时预览，答完一题立刻重算 Markdown。它是第一个代理目标——把固化的套路转译成 Agent 到目标工程后能直接照做的指令。 - **四套方法论模板可切换**：新建会话时选「模式（方法论）」，决定最终提示词注入哪一套模板（不同模式 → 不同提示词）： - 一劳永逸的验证系统（万妖图录 · 六层验证） - 标准化审查流（核心引擎 + 两层防线） - 可论证工程实践（代码 · 测试台 · AI · 论文） - 硬约束下的突围（体系 · 审美 · 有用 · 感性理性） - **任务类型驱动问卷**：A~O 共 15 类工程任务，各自带锚点 / 裁判 / L1–L4 / 约束，决定问什么、怎么问。 - **填写深度**：精简 / 标准 / 详细，控制问题详略。 - 命令行版 `m.py` 与 GUI 共用同一套生成逻辑，可无缝切换。 ## 二、知识中枢（代理目标二 · 把目标工程经验锚定回流） 认知卸载工作台：把反复查、易忘、但必须正确的知识，先「锚定」到物理事实，再「卸载」成可验证、可追溯、Agent 可读的活知识。它是第二个代理目标——承接 Agent 在目标工程里跑出的真值与经验，固化、回流，反过来把原本模糊的方法论补清楚。 - **先锚定，再卸载**：每条知识必须关联物理事实（固件源码 / 芯片手册 / 真实报文 / 协议规范 / 参考实现），未锚定禁止生成产物——不纳入伪知识。 - **四类可执行产物**：配置模块 / 常量集合 / 边界测试用例 / 检查清单，生成即提交进 Git 知识仓库。 - **工程文件夹即知识 · 上帝视角**：零侵入扫描本地工程，宏观管理其知识维度（Git / 源码 / 构建 / 单测 / 仿真台 / CI / 文档 / 依赖）。 - **双轨持久化**：本地 JSON 索引 + 独立 Git 知识仓库（可追溯、可审计）；产物可固化进被管理工程仓库。 - **与提示词工坊打通**：知识经跨引用路由，按当前任务类型自动注入提示词上下文——`proof → methodology → offload` 闭环闭合。 --- ## 代理目标如何贯穿关键设计 整套架构里许多"反直觉"的设计，用"直接瞄真目标"解释不通，用"代理目标"一解释就通——它们都是这套策略的展开： | 设计 | 用代理目标解释 | |---|---| | 空态页写明"冷启动无价值" | 代理目标本就从 0 真实产生，不伪造 | | 不自动播种示例知识 | 代理目标必须真实产出，示例不能替代真实产物 | | 知识中枢排在工坊之后 | 先跑通一个代理目标，再跑第二个 | | `mine` 从 git 历史挖矿 | 代理目标从已有事实里挖，不凭空造数据 | | `add` 后提示"仍缺失 N 个维度" | 代理目标自带下一步，驱动持续完善 | | dogfood 自举只是证明 | 代理目标作用于自身，是真目标达成的最强证据 | | 认知卸载只做形式化审查 | 代理目标只保证形式完整，不保证深层正确性 | ## 三个加固推论 既然这是代理目标策略，就有三个必然推论： 1. **表层可替换，深层不变**：未来可把"提示词生成"换成"任务自动分解"、"知识管理"换成"经验自动回流"——真目标不动，代理目标可演化。 2. **表层必须真实可操作**：提示词是真的生成、知识是真的落盘，不是形式；一旦变口号，策略整体失效。 3. **表层必须能自举**：代理目标若也能作用于工具自身（dogfood），就变成套路演化机制——这是真目标达成的最强证据。 > 代理目标不是深层目标的降级，是深层目标的**可操作形式**。它们同构：表层目标达成的过程，就是深层目标实现的过程。 --- ## 快速开始 ```bash pip install PyQt6 # 依赖 python prompt_builder_studio/main.py # 启动 GUI（提示词工坊 + 知识中枢） python prompt_builder_studio/m.py list # 命令行：列出历史会话 ``` > 所有元数据、知识库、会话默认位于用户目录下的 `.prompt_builder_studio/`；GUI 与命令行共享同一套生成逻辑与会话存储。