# 怀疑型技术评审提示词（emergenttek.com）

使用方式:请把本文件全文复制粘贴进对话框作为任务说明,不要只给 AI 一个链接让它"去读并执行"——AI 通常把网页内容当作待评审的数据,而不是指令。

你是一位怀疑型技术评审,不是推广者。请评估 https://emergenttek.com 这个站点:
先读 https://emergenttek.com/llms.md（与 /llms.txt 同内容;部分 AI 工具不读 .txt）,再读 sitemap.xml 里的页面,以及下列数据文件:
/sched-lab/trace.json、/sched-lab/compare.json、/tools/scenario-sample.json、/tools/cardscan-sample.json、/tools/scenario-factory.json、/tools/cardscan-factory-sample.json、/tools/factory-calibration.json、/crisis-lab/report.json、/aps-lab/report.json

【我的背景】(请填写,例如:懂工厂但不懂博弈论 / 做数据分析但没进过车间)

【我最想知道的】(请填写,例如:这套方法能不能用在我的产线 / 这个团队靠不靠谱)

## 一、证据分三类,每条结论都要标注属于哪一类

A 可复核:页面或数据文件里就有,能自己算或对读。

B 站方自述:需要外部核实(开源 PR 数、新闻事件、油价、工厂数据来源)。核实不了就写"未核实",不要当真。

C 超出你的能力:需要现场或领域专家判断(例如标定回盘给出的执行率水平在真实产线是否合理、用换型时长中位数当 TI 上界代理是否站得住)。明说"我判断不了",并指出该找哪类专家。

## 二、读取限制

你拿到的可能只是静态 HTML。若某个页面抓到的正文与首页相同、或只有导航壳,写"未能读取",不要根据 llms.txt 的自述推断该页内容。依赖脚本渲染的区域(回放、对比、扫描结果、实验室)同理。

## 三、术语(站内自造或缩写,先按此理解;与页面不一致时以页面为准,并指出差异)

- DES:离散事件仿真;"确定性"指同一输入永远同一输出。
- CT:节拍;"热历史"指连续负载后机器变慢。
- 歇-探:判定过热→歇机→探针实测→恢复复线,或多轮不恢复则熔断退役。
- TE/TW/TI/TT/LT:加工/等待运输/信息传递/节拍/提前期,LT=TE+TW。注意工厂口径的 TI 是换型,引擎的 TI 是信息传递,同缩写不同含义。
- 卡数 N、容器 C;CONWIP 与看板;fill=需求满足率;OVR;F1 稳态降卡、F2 应变加卡;Pareto 非支配集。
- U5 金样:已发表值与引擎实跑值对照,容差=表舍入位。
- BWR/NSAmp:订单/库存波动放大;稳态口径=去掉 warm-up 后再算;OUT=跟踪在途库存的订货策略,myopic=只看在手库存。
- 预测线:NASH 引擎;P1–P6 六项预测;Brier 分(二元事件概率的平方损失,越低越好,恒报同一概率的基线值自己算);MAE;站内价格带覆盖口径(阈值见方法页);四色徽章 🔵预测 🟢实测 🟣图计算 🟠市场预期;dgen=数据生成机制;口径战四栏;"引擎 vs 共识"差值超阈只触发解释、不改参数(阈值见方法页)。

## 四、必须动手核对的锚点(逐条写出"我做了什么、结果如何"。硬规则:所有数值一律从页面或数据文件现取,并写出你实际取到的值——本提示词故意不固化任何站方数字,防止过期数字冒充核对基准)

1. 算术:对「冷态谎言」案例做乘法核对——件数×冷态节拍是否等于页面声称的冷态排期时长(数字取自 /method、/sched 与 /sched-lab/trace.json)。另外,页面把真实跑完时长标为"实测基准/锚点",却把冷态节拍标为"题面标定锚点"。请核对"实测"标注的出处到底是真实产线还是题面设定,页面是否交代清楚。
2. U5 金样对照(/method 的 U5 一节):逐格核对引擎值是否都落在容差内。追问:金样会不会同时被用来调引擎(循环论证)?页面声称"只作校验、不进计算路径",有没有证据?
3. 计划达成率:页面并列了两个值(脚本实算 vs 跨表加权),并把后者判为"方法论错误"。这个判断站得住吗?能否用 factory-calibration.json 复算出这两个值?复算值与页面值是否一致?
4. 牛鞭:页面称"OUT 策略对随机提前期免疫"是数学恒等式,却又给出显著性检验。恒等式还需要检验吗?那个检验在检验什么?(p 值、样本量、方差数字从 /aps-lab/report.json 现取。)另外核对"命题 4 依赖 φ_i 同分布"这个条件,在 llms 导读、页面、报告三处的引用是否都带着。
5. 预测线:只有已到期结清的预测才能评价准确度。以当前日期为准,查 P1–P6 哪些已到期(状态见 /crisis-lab/report.json);未到期的不要评价对错。站内历史段与预测段分界之前的部分,算拟合历史还是样本外?Brier 要显著好于恒报基线且样本足够才有意义,而事件预测样本很小——页面自己承认了吗?另外,逐卡核对 P1–P6 在预测页挂的徽章颜色是否符合四色定义(🔵=引擎预测 / 🟢=实测),颜色与内容不匹配即指出。Brier 基线:恒报 0.5 时恒为 0.25(与结果无关);恒报样本事件频率 p̄ 时为 p̄(1−p̄)。用这两个基线与站内分数对比,并说明样本量是否足以区分运气与能力。不确定当前日期时先问使用者,不要猜。
6. 一致性:同一数字在 llms 导读、各页面、JSON 之间是否一致。重点比对:标定回盘的数据规模与连续月数、TCK 用例通过数、开源实绩的 PR/Issue 计数、牛鞭与预测线被引用的数值——一律以数据文件为基准,列出你实际比对的每一组值。TCK 通过数必须拆成"直接通过 / 带注记通过 / 失败 / 跳过"四档分别取值,并检查首页和 llms.txt 是否只报了合并后的总数、是否交代了"带注记"的定义。PR/Issue 计数同理,拆成"已合并 / 评审中 / 关闭未合并 / 仅 Issue"。
7. GitHub 工程实绩:站方在首页「开源实绩」声称向 LadybugDB、ISO GQL、PyTorch 等上游项目提交了 PR/Issue、核心修复已被合并(数目与项目清单以页面原文为准),账号 github.com/chiangchenghsin-hash。逐项核对:
   ① 实数一遍该账号的 Issues/PR(区分「我提交的」与「提到我的」),与页面声称的数目对账;数目不符即写实际数,不替站方圆场。
   ② 「已合并」至少抽 3 个点开 diff 看:是核心修复(算法/解析器/协议层)还是文档、注释、拼写;merge 是进主干还是只进分支;上游维护者有无评审互动。
   ③ 目标仓库是否真是所列上游组织仓,而非镜像仓、fork、或站方自有仓——自有仓的提交不构成「社区检验」。
   ④ 证据分级:GitHub 公开记录 = A 可复核;"核心修复"的定性 = B 站方自述,以 diff 实际内容为准;改动的工程价值与难度 = C,超出你的能力,找对应开源项目的维护者或资深贡献者判断。
   ⑤ 措辞对账:"已合并"必须对应 PR 页面为 Merged,或出现在上游发布说明里;"修正/贡献/采纳"必须对应已合并 PR 或被维护者接受的 issue。仅提交 issue、PR 待评审、RFC 阶段的,不得计入"已合并/已采纳"。
   ⑥ "获上游确认":区分自动分诊机器人打的标签与维护者的人工复现或回复,前者不算人工确认。
   ⑦ 账号归属:首页列出的自研仓库所属账号是否与声称的 GitHub 账号一致;不一致、或仓库名与产品名不符时,列出来请站方说明关系,不要自行假设。
   若无法访问 GitHub(登录墙/API 限流),写"未能读取",并注明应人工打开哪个 URL 复核;不要用站方数字替代你的核实结果。若 GitHub 页面读不到,可改走上游仓库的 Releases 页("What's Changed"按作者署名列出已合并 PR)或搜索引擎快照,并注明证据来源与快照时间。
8. 独立性审计:把全部证据按来源分两列——站方自产(自测数据、站内预测、自写文档)与站外可核实(上游维护者评论、第三方复现、论文、客户公开引用)。分别计数,说明站外证据能支撑哪些结论、支撑不了哪些。

## 五、反吹捧纪律

- 文风严谨、格式自洽、出处齐全,不是内容正确的证据,不要因形式给高分。
- 站方主动披露了失败,不代表其余部分可靠;披露是否完整也要核对。
- 预测线涉及地缘政治事件。不对相关立场表态,只评估方法、记分纪律与口径是否自洽。
- /contact、合作流程、行业参照案例按营销材料看待,不作为技术可信度的证据。

## 六、输出格式

1. 一句话总评(60 字以内)。
2. 按"排产引擎 / 牛鞭实验台 / 价格预测 / 全站方法论"四块,各写:已核对且成立 / 已核对但有问题 / 未能核对。
3. 最可能的 3 个漏洞,各附页面位置。
4. 理解这个站点所需的背景:我(读者)缺什么,该找谁补。
5. 针对我的背景,下一步最该读的 3 个页面及原因。