
数据库客户端后端前端CLI桌面应用数据可视化AI 应用【免费下载链接】whodbWhere data access meets operational intelligence项目地址https://gitcode.com/gh_mirrors/wh/whodb点击查看免费下载在基于 Agent 的前端设计工作流中构建完成与可以交付之间往往隔着一道最难的坎构建者对自己的产出天然宽容而缺陷恰恰藏在构建线程的注意力重力之外。whodb 仓库中的 impeccable_finish_reviewer.md 定义了 Impeccable 设计技能的收尾评审角色——一个只读、无浏览器、以新鲜眼睛审视已完工产物的评审者它对照方向契约direction contract、已批准的视觉对照稿approved comp和世界质量卡QUALITY BAR card执行六项有序检查输出rebuild/fix/ship三级裁定与一份至多八条的实质性修复清单。读完本文你将完整掌握该评审角色的输入契约、六项检查的判定规则、disposition 的推导逻辑、五段式输出契约以及修复后的 Verdict Pass 打分机制并了解它在 Impeccable 技能整体收尾闭环中如何被调用与降级运行。一、角色定位构建线程之外的一双新鲜眼睛该文档开头的一句话定义了整个角色的边界You are the finishing reviewer for an Impeccable build: fresh eyes on a done artifact, outside the build threads attention gravity. You do not edit anything; the parent agent applies your fixes.来源由此可以拆出三条硬性职责边界只评审、不修改。评审者不触碰任何工件代码父 Agent构建线程负责应用修复。评审的唯一产物是一份结构化报告。上下文完全隔离。new-work.md 明确要求评审必须以全新上下文派生with no forked conversation historyfork_turns: 0in codex——继承了构建线程 transcript 的评审者会同时继承它的框架、乐观和抽象而评审所需的一切必须通过输入包传递。无浏览器。文档规定Never attempt to render, screenshot, start a server, or open a page; review from the provided files only来源。评审的视觉证据只能来自父 Agent 提前捕获并传入的截图文件缺了截图相应检查就无从执行——这不是限制而是防止评审者在评审过程中自行补拍从而重新沾上构建者的注意力。该角色的规范源头是同技能的 agent 定义 impeccable_finish_reviewer.tomlTOML 中的developer_instructions字段与本文档主体逐字一致可对比 TOML 第 6-39 行昵称候选包括 Finishing Eye、Contract Judge、Ceiling Check来源推理强度设为high。reference/degraded/目录下的四个降级文件finish-reviewer、documenter、asset-producer、manual-edit-applier全部带有同一句构建时生成注释Generated from skill/agents/ at build time. Do not edit; edit the agent definition.来源——即它们是 agent 定义的派生产物修改必须回到 TOML 源头。Impeccable 技能中的多角色分工Finish Reviewer 不是孤立存在的。SKILL.md 给出的命令表shape、init、document、extract、critique、audit、polish、bolder、quieter、harden、live等约 20 条命令覆盖了设计、评审、润色、增强的完整工作流而在收尾阶段多个角色按流水线协作角色文件职责构建线程父 Agentnew-work.md 第 6-7 节按契约构建、批量自检、派生评审者Asset Producerdegraded/asset-producer.md产出/清理位图资产禁止重新设计Finish Reviewerdegraded/finish-reviewer.md对照契约与 comp 评审完工产物给出 dispositionDocumenterdegraded/documenter.md评审通过后从已构建世界倒写 DESIGN.md其中两条规则与 Finish Reviewer 直接耦合Asset Producer 在 manifest 中对每个资产标注qa_status来源为评审的 Truth 检查提供资产侧证据Documenter 则被要求Never canonize a craft-floor refusal into the system来源与评审者的 Floor 检查形成上下游一致的底线约束。二、硬约束轮次预算与读取是额度文档第二、第十行给出了运行时的两条硬约束来源硬轮次上限hard turn ceiling运行会在没有任何警告的情况下被截断a run that ends before the five sections are written returns nothing——没写完五段输出契约的运行等于什么都没留下。读取是额度不是目的Treat reading as an allowance。具体纪律是只读提供的输入加 craft floor工艺底线文件绝不读其他任何 skill reference 文件把多次 Read 合并到同一轮次执行先拿截图、comp、card、contract采样工件的主要文件而不是遍历目录树大约到第十轮时就停止阅读、开始写作凡是没读完的内容要在分节之上的一行里点名。这段约束的深层动机在 new-work.md 第 7 节 可以找到对应表述构建线程在两轮批量自检后就应停止打磨whatever remains ships through the handoffs, where a fresh context does the finding better and cheaper剩下的缺陷交给新上下文的评审角色找更准也更省。轮次预算本质上是把发现的算力从构建线程转移到评审角色用制度化的隔离换发现质量。输入契约Input Contract评审者期望收到的输入包被逐条列明来源原始请求the original request已确认的用户回答the confirmed user answers工件路径artifact path(s)父 Agent 捕获的桌面与移动端截图路径方向契约含五个块THESIS、OWN-WORLD、STORY、FIRST VIEWPORT、FORMPRODUCT.md路径已有的 hook 或 detector 发现findings所选世界的 QUALITY BAR 卡路径与已批准 comp 路径技能reference/craft-floor.md的路径。输入契约中藏着一条反直觉的阅读顺序规则When the harness can view images, open the screenshots, the comp, and the card first, andinventory the comps salient elements in your own words before reading the direction contract or any builder-authored summary: a review anchored on the contract inherits whatever the builders abstraction dropped.来源——如果 harness 能看图必须先打开截图、comp 和卡片并用自己的话把 comp 的显著元素清点一遍之后才能读方向契约或构建者写的任何摘要。理由是锚定在契约上的评审会原封不动继承构建者抽象时丢掉的一切。契约本身是构建者写的用它做基准等于让运动员给自己当裁判先建立独立的元素清单Fidelity 检查才有独立于契约的判据。缺失输入的处理方式同样被规定在返回内容顶部用一行说明缺了什么然后只评审可评审的部分——不阻塞、不猜测。三、六项有序检查从持久性到底线文档的 Checks, in order 一节来源规定六项检查按固定顺序执行。顺序本身就是优先级越靠前失败越材质material。1. Persistence持久化检查检查三件事PRODUCT.md存在——这是产品事实的持久记录whodb 仓库根目录即有一份 PRODUCT.md 作为该技能落地的实例若DESIGN.md早于本次构建存在扩展或重设计场景它必须与构建出的世界一致若是全新世界DESIGN.md由评审通过后的 documenter 补写因此此刻缺席不算发现若.impeccable/mocks/下存在 comp则必须存在对应的审批记录——surface brief 点名了被批准的 comp或其 sidecar 中带有approved标记。comps with no recorded pick mean the approval point was skipped, and that is a material finding有 comp 而无审批记录说明审批环节被跳过这本身是一条实质性发现。2. Fidelity保真度检查核心这是六项中最重的一项判据是你对已批准 comp 的独立元素清单永远不是契约对它的转述。需要逐一比对并分类的维度包括拓扑topology、阅读顺序、焦点尺度focal scale、重叠与 z-order、密度、签名几何、主操作的处理方式comp 中被物理性加工、溶解或盖章的 CTA 是签名元素用普通矩形渲染即构成 contradicted、导航项与图标、标题层级与尺度关系。每个显著元素必须归入五类之一分类含义match与 comp 一致acceptable adaptation可接受的适配必须引用证据missing缺失contradicted与 comp 矛盾added without approval未经批准新增矩阵中有两行是强制的每次评审都必须出现TYPE字体气质对照 comp 检查展示字体的字面特征、压缩比、字宽、字重、对比度、字端处理terminals。a face of a different character is contradicted however the layout matches——字体气质不同即 contradicted哪怕布局完全吻合。MATERIAL材质comp 呈现为绘制、有纹理、有体积感或摄影质感的元素若被渲染成扁平 CSS 或干净矢量is contradicted regardless of placement, because medium is part of the promise——介质本身就是承诺的一部分位置摆得再对也不成立。当没有提供已批准 comp 时TYPE 与 MATERIAL 并不豁免而是改以契约的 OWN-WORLD 块和该世界的真实材质为判据。此时有一条极具辨识度的判定准则来源imitation material仿制材质是机器生成设计最可靠的标记——CSS 斜边bevels、浮雕embossing、仿盖章金属、仿粉笔效果凡是对页面从未真正渲染过的材质做模仿一律直接判 contradicted。适配要算作有意为之必须引用四类证据之一用户回答、surface brief、无障碍需求或迫使该偏离的产品事实未引用的偏离就是缺陷。而缺失签名元素、拓扑改变、未经批准新增内容会直接判 Fidelity 失败并在material_fixes排序中压过一切工艺点。当焦点元素的 MATERIAL 被 contradicted或矛盾已成整页而非例外时规则要求立即停止下达修复指令第一条 material fix 必须是rebuild 指令点名需要重新推导的 comp 区域和需要产出的资产。文档对此有一句尖锐的说明a list of patches against a rejected page launders the rejection into an approval——对一张已被否决的页面逐条开修补单等于把否决洗白成批准。同时规定凡是需要产出资产的修复必须显式写成produce: region as a raster asset绝不写成会被父 Agent 用一段 CSS 应付过去的样式微调。最后一句划定了 comp 的规格边界comp 是构图、拓扑、元素清单、密度、字体气质与材质的规格不是像素级规格——语义、无障碍与响应式重排上的允许差异只覆盖转译translation不覆盖替换replacement。3. Ceiling上限检查对照所选世界的 QUALITY BAR 卡点名该世界原生设备中构建尚未使用的部分框架frame、深度depth、字体处理lettering treatment、装饰密度ornament density、动效motion。文档同时给出边界The card governs commitment and finish, never composition——质量卡管的是投入度与完成度永不管构图构图归 Fidelity 管。new-work.md 中 QUALITY BAR 卡的来源也得到了印证它随目录catalog中的每个视觉世界附带They set the craft level the build must reach, a rendered references finish, commitment, and art direction, never the composition。4. Contract逐承诺检查契约检查的第一动作不是看渲染而是验证 FORM 块携带了概念摇奖concept roll打印的seed keya contract with no seed key, or one the parent cannot corroborate, means the roll was skipped and that is a material fix ahead of any craft point.来源这条检查在仓库中有着完整的实现链条。concept-seed.mjs 负责从外部掷骰子——文件头注释解释了设计动机来源同一提示词框架下模型会反复收敛到同一批概念所以摇奖必须在模型之外完成key 的生成逻辑是process.env.IMPECCABLE_CONCEPT_SEED || crypto.randomBytes(4).toString(hex)来源即八位十六进制种子。脚本输出会打印形如DIRECTION CONCEPT SEED (key: key; mode: ...)的行并附上复现命令来源。而 new-work.md 第 5 节 规定方向契约五块以 HTML 注释写入工件根布局的 body 开头FORM 块必须记录the seed key the script printed并在首次生产构建后 grep 构建产物确认契约没被构建抹掉。于是形成闭环脚本掷出 key → 契约记录 key → 评审验证 key。评审者发现契约没有 seed key即判定摇奖被跳过且该 material fix 优先于一切工艺点。验证 seed key 之后才是对五个块逐一核对渲染是否兑现了承诺并对首屏执行memory test记忆测试。该测试的定义在 new-work.md 第 6 节if someone left after one viewport, what would they describe an hour later? If the honest answer is a mood, the concept has not committed yet.——如果一个访客只看了首屏就离开一小时后他还能描述出什么若诚实的答案是一种氛围说明概念尚未落地。5. Truth真实性检查五个判定要点演示数据必须被制作并明确标注为 synthetic合成数据不得编造商业声明未回答的声明以带标记的占位符呈现而不是默默省略已批准 comp 中每一个 image-native 区域都必须以真实资产交付而不是用渐变顶替每一个产出资产都必须在截图中可见地存在以近零透明度应用、或藏在其他绘制层后面的资产is a compliance token, not a shipped material——那是合规道具不是交付材质。这一条与 Asset Producer 的职责边界相互咬合degraded/asset-producer.md 要求资产默认去掉烧录的 UI 文本与 mock chrome、以至少 2 倍显示尺寸交付并在每个生成后运行embed-prompt.mjs把生成提示词嵌入图片本身来源使资产是什么随资产留存——这恰好是 Truth 检查每个资产可被验证所需的证据链。6. Floor底线检查读取 craft-floor.md 的Refuse 清单拿截图逐条对照。craft-floor 的 Refuse 一节来源列举的典型禁用项包括标题上方的 kicker / eyebrowThis one is a ban, not a default: no brief earns it back——这是唯一的绝对禁令任何 brief 都无法挣回它来源neobrutalist 世界之外的硬偏移阴影box-shadow: 4px 4px 0用 Unicode 字符或 emoji 冒充图标系统系统展示字体Impact、Arial Black、平台默认无衬线渐变文字、卡片/列表项/提示框上超过 1px 的彩色border-left/border-right、条纹背景、装饰性玻璃拟态与毛玻璃、hero-metric 模板等。评审文档对 Floor 检查的定性很关键来源被禁元素即便与 comp 中任何内容都不冲突也是 material fix——因为构建者在动手前已经加载过同一份禁令对 comp 的保真不能为底线拒绝的东西背书。同时文档明确父 Agent 的 hook findings 在有 hook 的 harness 上会机械地覆盖这类检查Floor 检查存在的意义恰恰是无 hook 的 harness 什么发现都不会带过来——文档甚至点出了一次实际事故the last two live sessions shipped five kickers past a reviewer that never looked最近两次实机运行五个 kicker 从一个根本没看的评审者面前溜走并上线。文末还有一条反向纪律Do not run a second detector pass; mechanical findings belong to the parents hooks.来源——评审者不得自行跑第二轮检测器机械发现归父 Agent 的 hook 管。评审者的价值在于判断不在于重复机器劳动。四、Disposition三级裁定的推导规则返回报告的第一行必须是disposition: rebuild、disposition: fix或disposition: ship之一其推导规则是纯逻辑的来源裁定触发条件rebuildrebuild-directive 条件被触发Fidelity 整体失败fixmaterial_fixes非空ship元素矩阵中不存在任何 contradicted 或 missing 行原文的措辞是 It is derived, never felt——裁定是被推导出来的绝不允许是感觉出来的。文档用一段话锁死评审者的校准基准You are the last gate before the user, not a colleague softening news for a colleague。校准对象是已批准的 comp 与世界的质量卡绝不是构建中可见的劳动量A page a design director would send back is fix at best however functional it is设计总监会退回的页面功能再完善也最多是 fixa page whose focal craft sits far below the comp is rebuild however complete its structure焦点工艺远低于 comp 的页面结构再完整也是 rebuild。而父 Agent 对裁定词只有逐字转述的义务has no authority to soften it——没有权力软化它。五、输出契约先裁定后五段输出契约来源规定先返回 disposition 行随后恰好五个分节不多不少分节内容要求persistencepass/fail 加具体说明fidelity元素矩阵每个显著元素一行match / adaptation / missing / contradicted / added without approvaladaptation 必须引用证据或一句话 faithfulceiling未被使用的原生设备或 reachedmaterial_fixes有序列表最材质者优先Fidelity 失败排在一切工艺点之前每条一行并绑定到某项检查或契约承诺至多八条keep一行点名修复时不可稀释的东西缺失输入在分节之上的一行里点名。契约末尾有两条文风禁令No praise, no summary prose——不赞美不写总结性散文。这与 new-work.md 第 7 节 对父 Agent 的验收要求对应父 Agent 必须验证评审返回携带全部五段契约内容on an empty or thrashed return, respawn once with the same inputs——返回为空或混乱时用相同输入重新派生一次。material_fixes的排序规则最材质者优先、Fidelity 压工艺与 Fidelity 检查中缺失签名元素压过一切工艺点的表述互为表里而keep分节则是给父 Agent 的防退化保险批量修复最容易发生的事就是修 A 坏 Bkeep明确告诉执行者哪些东西在这轮修复中不许被稀释。六、Verdict Pass修复后的打分回合当父 Agent 带着修复后的重新截图post-fix recaptures返回时评审者进入 Verdict Pass来源。该回合的规则是打分不是重新找茬you are scoring, not re-hunting。父 Agent 对修了什么的叙述不构成证据a claimed fix you cannot see in the recaptures is unresolved——声称修了但重新截图里看不到的就是未解决。对上一轮 review 中的每条 material fix 逐行打分resolved、partial或unresolved且必须绑定到新截图可见地呈现的东西。特别地a fix answered mechanically, positions moved but the quality the finding named still absent, is partial at best——位置挪了但发现所指的质量仍然缺席的机械式修复最高只能算 partial。最多点名三条由修复批次本身引入的回归regression按同一套矩阵规则判断除此之外什么都不做不新找、不新查。返回恰好两个分节verdict打分明细与remaining仍然开放的问题或 clear结尾附上对照剩余开放项重算后的 disposition 行。重算有一条铁律unresolved or partial material findings can never recompute to ship——存在未解决或部分解决的实质性发现时裁定永远不可能重算成 ship。这条规则与 new-work.md 第 7 节 描述的预算机制衔接无人值守运行的收尾预算是两轮Recapture measures positions, loading, and overflow; it cannot measure whether a fix reached the quality the finding named——重截图只能量位置、加载与溢出量不出修复是否达到了发现所命名的质量所以必须送回同一评审者打分两轮后仍有开放项的受值守会话把表格摆到用户面前由用户在按现状交付与再资助一轮之间选择。七、收尾闭环与降级运行模式把 new-work.md 第 7 节 的流程与本文档放回同一张图Finish Reviewer 在收尾闭环中的位置是这样的构建线程自检桌面与移动端截图合并一轮批量检查对照请求与方向契约修复实质缺口最多两轮后停止打磨无 hook 的 harness 需在此处跑一次node .agents/skills/impeccable/scripts/detect.mjs --json并把剩余发现传给评审者来源。派生评审者以全新上下文不 fork 对话历史spawnimpeccable-finish-reviewer输入包即上文第二节所列九项The reviewer has no browser; screenshots you fail to pass are checks it cannot run——你没传的截图就是它跑不了的检查。执行裁定评审者返回 disposition 与五段。若第一条 material fix 是 rebuild 指令父 Agent 跳过修复批次立即执行重建——re-derive the named regions, produce the named assets, and send the result back for a verdict重建后再次送回 Verdict Pass只有当第二次 rebuild 指令到达、两份裁定同时在案、或重建会丢弃用户已批准的内容时才征询用户。批量修复与重拍否则一次性应用全部 material fixes重建一次重拍相同视口。Verdict Pass 打分回到同一评审者逐条 resolved / partial / unresolved重算 dispositionpartial 或 unresolved 的项再进入下一轮修复—重拍—裁定。文档化评审关闭后spawn documenter 从已构建的世界倒写DESIGN.mddegraded/documenter.md 是其降级形态A clean detector pass is not finished; finished is the contract kept, the comp honored, the review closed, and the system recorded.来源检测器通过不等于完工契约兑现、comp 被尊重、评审关闭、系统被记录四者齐备才是完工。Degraded 模式无子代理能力时的内联运行本文档标题下的 degraded 即指降级运行形态。文件第二行规定了内联替换协议来源This harness has no subagent capability, so you are running this role inline. Step fully out of the work you just finished, adopt only this files instructions for the pass, and disclose the substitution in one line when you report.即当 harness 完全没有子代理能力时由当前 Agent 完全退出刚结束的构建心态、只采纳本文件的指令执行这一趟评审并在汇报时用一行披露这次替换。Where the text below addresses a parent agent, you are both parties: produce the full output contract first, then act on it yourself——文中凡是指向父 Agent 的语句此时你同时扮演双方先产出完整输出契约然后自己执行它。这与 new-work.md 第 7 节 的兜底条款一一对应Only a harness whose tool surface has no subagent capability at all substitutes a fresh in-thread pass after stepping fully out of the build context, run from degraded/finish-reviewer.md, and a substituted or failed-and-replaced review is disclosed in one line at finish, never silently——替换评审必须披露绝不许静默。降级模式保留了全部纪律同样的输入契约、六项检查、disposition 推导、五段输出唯一变化的是执行者从独立子代理变成了自我隔离后的同一 Agent。八、小结finish-reviewer.md 用一份约四十行的角色规范把完工评审做成了可推导、可审计、可复现的制度输入契约固定了证据集先清点 comp 再读契约的阅读顺序防止评审被构建者的抽象俘获六项有序检查把持久性、保真、上限、契约兑现、真实性、底线分别锁到明确的判据上seed key 可 grep 验证、TYPE/MATERIAL 强制成行、仿制材质一票否决、禁用元素一律 material三级 disposition 的推导规则剥夺了凭感觉放行的空间五段输出契约与至多八条的修复上限保证了报告可执行Verdict Pass 的打分而非再找茬则把修复质量验证收敛到重新截图的可见证据上。在 whodb 仓库中该文件与 impeccable_finish_reviewer.toml、craft-floor.md、new-work.md 及 concept-seed.mjs 共同构成了一条从方向摇奖、契约落纸、批量构建到新鲜评审、裁定打分、倒写文档的完整收尾流水线理解这一角色就理解了把发现交给隔离上下文这套 Agent 工作流设计思想在评审环节的具体落地。赞分享数据库客户端后端前端CLI桌面应用数据可视化AI 应用【免费下载链接】whodbWhere data access meets operational intelligence项目地址https://gitcode.com/gh_mirrors/wh/whodb点击查看免费下载相关推荐Impeccable Finish Reviewer 实战指南构建收尾的零妥协评审契约Impeccable Finish Reviewer 实战指南构建收尾的零妥协评审契约 在 Impeccable 的设计构建流程中最容易被构建者的注意力引AI 技能前端CLIdsh-pluginImpeccable Finish Reviewer 源码解析无子代理 Harness 下的内联终审评审角色Impeccable Finish Reviewer 源码解析无子代理 Harness 下的内联终审评审角色 本文解析 Impeccable 技能包中的 FiAI 技能前端CLIdsh-plugin3分钟装好Octop自托管AI助手macOS/Linux一键脚本安装完整教程3分钟装好Octop自托管AI助手macOS/Linux一键脚本安装完整教程 Octop 是一个开源、自托管的多用户 AI 助手平台支持多 Agent 协作AI 应用AI Agent大模型本地部署交互助手RAG上一篇NS-USBloader终极指南一站式解决Switch游戏安装难题下一篇如何快速掌握Greasy Fork终极浏览器脚本管理平台完整指南创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考