Kimi K3 完成 V3 Landing Page 的全过程复盘

主题：从原始 Prompt、任务拆解、第一次设计、用户纠偏，到第二次重构和最终交付

分析对象：Kimi K3 × Kimi CLI 在 joyehuang/blog 中的一次真实长程前端任务

日志时间：2026-07-20 22:39:03 — 2026-07-21 01:58:30（Australia/Melbourne）

结论性质：单个真实任务的行为样本，不是通用模型 Benchmark

0. 先给结论#

这次任务最值得研究的，不是“K3 能不能写出一个好看的页面”，而是：

K3 的工程执行能力明显强于它第一次对“从 0 设计”这条语义约束的守护能力。

第一次方案已经具备完整的创意、代码、动画、双语路由、测试和视觉验证，但它把“创新”主要集中在前 6 秒的入场动画，页面主体仍沿用了 V2 的组合方式：固定导航、左大字标、右头像，以及“数字 → 作品 → 写作 → 联系”的作品集叙事。

因此，第一次失败不是“页面做得差”，而是：

它交付了一个技术上完成度高、视觉上也不错，但没有忠实满足最高优先级语义约束的方案。

用户指出问题后，K3 的表现发生了明显变化：

• 它没有辩解，而是准确指出自己搬用了 V2 的哪些骨架。
• 它把“页面自我构建”从一个入场 gimmick，升级成了整个页面的交互范式。
• 它一次给出三个差异足够大的新方向，而不是三个视觉小变体。
• 选定“Agent 会话即主页”后，它完整推翻第一版，重新实现、截图验证、测试、构建、提交并推送。

最终结果说明，K3 具备很强的长程实现、视觉调试和反馈恢复能力；但这次日志也暴露出它需要外部反馈才能激活的“事后批判能力”。如果在第一次写代码前加入一次独立的原创性审查，本次约 64.6 KB、约 2,326 行的第一版实现很可能可以避免被整体丢弃。

我的综合判断是：

综合评分约为 7.8/10。这个分数不是对 K3 的普遍排名，而是它在这一次任务中的表现快照。

1. 分析方法与证据边界#

本报告交叉读取了五类证据：

1. Kimi 会话上下文：context.jsonl
2. Kimi 事件流：wire.jsonl
3. K3 写出的正式实施计划：echo-batwoman-shadowcat.md
4. 两轮页面的截图和浏览器验证记录
5. 最终 Git 分支、提交和实际代码

关键本地证据：

• 原始 Prompt 与会话上下文
• Kimi 事件流
• 第一版正式计划
• 最终 V3 页面
• 最终动画与交互引擎
• 中文 V3 路由
• 英文 V3 路由

需要特别区分三种结论：

• 已验证事实：日志、工具调用、代码或 Git 状态直接证明。
• 行为推断：根据动作序列推断 K3 的决策倾向，例如“受到 V2 锚定”。
• 不可从本任务得出：K3 的训练数据、底层模型架构，以及它在所有前端任务上的平均能力。

严格来说，这次结果属于：

K3 模型能力 × Kimi CLI 系统提示 × Plan 模式 × 子 Agent × 浏览器工具 × 当前 Repo 内容。

所以，不能把每个动作都简单归因于“纯模型智力”。后文会把模型行为和 Harness 影响分开。

2. 原始 Prompt 到底要求了什么#

用户的原始 Prompt 是：

现在所在的 repo 是我的个人博客，我希望你现在开一个新的分支，然后为我的博客从 0 设计一个新的 landing page 和对应的入场动画，来展示 Kimi K3 的前端能力。我不会给你一个特定的赛道或者风格，我需要你自己去阅读我的代码、我的内容、理解我的博客，然后选择一个你觉得最为合适的风格。我的要求只有一个，那就是抓人眼球。我需要一个 landing page，无论是我的读者、粉丝，还是 HR、技术面试官，看到都会被惊叹到，然后想更加深入地了解我这个人。

日志位置：context.jsonl 第 25 行。

2.1 这段 Prompt 的真实需求层级#

它不是一个普通的“写个页面”任务，而是至少包含六层要求：

如果把它压缩成一句“任务合同”，应该是：

在理解 Joye 本人和现有博客后，独立发明一套新的视觉语言与叙事结构，用 Landing Page 和入场动画证明 K3 的前端创作能力，并让多类访客产生继续了解 Joye 的欲望。

2.2 Prompt 写得好在哪里#

这段 Prompt 已经给了模型很好的创作空间：

• 没有用具体风格词限制模型。
• 没有让模型只模仿某个站点。
• 明确要求先理解人，再设计页面。
• 给了清楚的多受众目标。
• 把页面本身定义为 K3 能力展示，而不只是信息展示。

因此，第一次方案过度借鉴 V2，不能简单归因于“用户 Prompt 不够清楚”。

2.3 唯一真正危险的歧义：“从 0”#

“从 0”至少可能有四种解释：

1. 新建代码文件，不修改旧页面。
2. 不直接复制旧组件实现。
3. 不复用旧页面的视觉语言和布局骨架。
4. 从人物与受众出发，重新发明信息架构、交互隐喻和视觉叙事。

K3 第一次主要满足了 1 和 2，但用户真正要的是 3 和 4。

这是本次任务最核心的错位：

K3 把“从 0”解释成了代码与文件层面的新建，用户把“从 0”定义为设计概念与信息架构层面的原创。

一个更稳健的 Agent 应当主动把它翻译成如下内部约束：

K3 在用户纠偏后才明确说出了这张表的本质，但第一次规划前没有建立它。

3. K3 是怎么拆解任务的#

3.1 第一层：三个并行探索 Agent#

22:39:39，K3 同时启动了三个 Explore Agent：

三份任务提示都很具体。例如人物 Agent 不只是读 site.config，还被要求查看文章主题、代表作开头、个人气质和可用于 Landing Page 的原文；技术 Agent 不只是列依赖，还要阅读现有视觉效果最强的组件。

三个 Agent 的结果分别出现在 context.jsonl 第 34–36 行。它们帮助主 Agent 提取出：

• “student-builder”“build in public”的人物定位。
• 100+ Agent 面试、4 段 AI 团队经历、开源项目、双语长文、社区分享等可信证据。
• “Build fast, learn faster.”、“知识是地基，context 才是护城河”等可用文案。
• 摄影 f/1.4、大提琴、Agent Harness 等个人化视觉动机。
• Astro、双语路由、GSAP、ScrollTrigger、语义 token 和 reduced-motion 等工程约束。

这是一次质量很高的横向拆解。它体现了 K3 的一个明显优点：

面对开放式任务，它会先建立“人、产品、系统”三张地图，而不是直接写页面。

3.2 第二层：主 Agent 亲自核验关键文件#

子 Agent 返回后，主 Agent没有直接照抄总结，而是又阅读了：

• /v2 的薄路由页面。
• 作品集 Repo 数据。
• BaseLayout 与 chrome={false} 管道。

这一步是好的 Agent 习惯：子 Agent 负责扩大检索面，主 Agent 对决定架构的关键事实再次核验。

3.3 第三层：只问一个高价值问题#

K3 没有反问用户喜欢什么颜色、什么风格，因为用户已经明确授权它自行选择。它只问了一个会真正影响代码结构的问题：

新 Landing 是直接替换 / 与 /en，还是先放在 /v3 与 /en/v3？

用户选择 /v3。问答见 context.jsonl 第 46–48 行。

这是一个值得学习的点：

不要把已经被授权的创意决策重新甩回用户，只澄清会改变工程边界的事项。

3.4 第四层：形成单一方案并进入 Plan 审批#

K3 把第一次方向收敛为：

“The Page That Builds Itself / 自我生成的页面”

其叙事是：输入 Prompt → Agent 思考流 → 扫描博客数据 → 线框蓝图绘制 → 色彩和内容注入 → 真实页面接管。

正式计划覆盖：

• 目标与人物画像。
• 约 6 秒入场动画时间轴。
• Nav、Hero、数字、作品、写作、Outro 五章。
• 双语数据和路由。
• GSAP、SVG、Canvas、主题、analytics、a11y、reduced-motion。
• Check、Test、Build、截图和性能验证。

从工程计划质量看，这份计划是完整的。问题不在“有没有计划”，而在计划中已经出现了未被识别的冲突：

它一边写“从零设计”，一边写“沿用 V2 已验证的架构”，随后又采用了与 V2 相似的页面骨架。

计划原文可见 第 12 行 和 第 36–43 行。

3.5 这次拆解缺了什么#

三个调研流都很强，但缺少第四类角色：原创性审查者。

更理想的拆解应当另外包含：

• 一名“盲创意 Agent”：只读人物与内容，不读 V2，提出三个原创页面隐喻。
• 一名“反抄袭/反锚定 Critic”：列出 V2 的可识别骨架，检查新方案是否重合。
• 一名“受众旅程 Agent”：分别模拟读者、粉丝、HR、技术面试官前 5 秒、30 秒和完整浏览后的感受。
• 一个实施前 Gate：先比较三套概念，再决定是否进入完整编码。

K3 的实际拆解是：

人物研究 ─┐
路由研究 ─┼─> 单一创意方案 ─> 详细计划 ─> 全量实现
技术研究 ─┘

更稳健的结构应是：

人物研究 ─┐
路由研究 ─┼─> 3 个概念 ─> 原创性审查 ─> 受众审查 ─> 小原型 ─> 全量实现
技术研究 ─┤
V2 禁用清单 ─┘

4. 完整执行时间线#

5. 第一版：为什么“做得不错”仍然是不合格#

5.1 第一版的创意并不差#

第一版核心概念“页面自我构建”其实有清晰的个人化逻辑：

• Joye 是 Agent 工程师，因此页面通过 Agent 执行过程出现。
• 读取真实博客数据，展示文章、团队、Stars 和面试数量。
• 用 f/1.4、头像显影呼应摄影爱好。
• 用蓝图和 DOM 交接展示前端工程能力。
• 页面角落保留 designed & built with kimi k3。

入场动画也不是纯文案概念。第一版引擎确实实现了：

• 终端命令逐字输入。
• Agent thought stream。
• 根据真实 DOM 的 getBoundingClientRect() 生成 SVG 蓝图轮廓。
• strokeDashoffset 描边绘制。
• Overlay 淡出并交接给真实 Hero。
• 24 小时门控、跳过、Esc、超时兜底和 reduced-motion。

也就是说，第一次失败不是“空想而没有实现”。它是一个实现完成度很高的错误方向。

5.2 真正的问题：创新只发生在入场层#

计划把完整页面设计成：

玻璃导航
→ 左侧巨大 JOYE + 右侧头像 Hero
→ Proof in numbers
→ Selected work
→ Writing
→ Outro / Contact

而 V2 本身已经具备相似的：

固定导航
→ 左侧主视觉/文案 + 右侧视觉对象
→ Evidence / 数字
→ Work / 项目
→ Writing / 内容
→ 联系与结尾

第一版的新意主要存在于“进入页面之前”；进入真实页面后，访客仍然会看到熟悉的 V2 亲属结构。

这也是 K3 后来自己给出的准确复盘：

“新瓶子装旧酒，除了前 6 秒，页面本质上还是 V2 的亲戚。”

对应日志见 context.jsonl 第 402 行。

5.3 为什么 K3 会被 V2 锚定#

从任务拆解可以看到一个很典型的 Agent 失败机制：

1. K3 要求技术 Agent 阅读“视觉效果最强”的现有组件。
2. 技术 Agent 明确把 ImmersiveHome.astro 称为“最接近视觉惊艳 Landing Page 的现有资产”。
3. 路由 Agent 也突出 /v2 是完整沉浸式首页。
4. 主 Agent随后亲自阅读 V2 路由、主组件和 Intro 实现。
5. 计划阶段为了保证可落地，优先选择了已验证的页面结构和 GSAP 模式。

这使得上下文里“如何理解 Joye”与“如何做成 V2 那样可落地”绑定在了一起。

换句话说：

K3 的研究做得越充分，V2 在上下文中的显著性反而越强；没有反锚定机制时，优秀参考物会变成设计吸引子。

5.4 这是模型能力的哪一种不足#

不是代码能力不足，而是三种高层能力没有同时成立：

1. 约束排序不足：把“工程可行”和“视觉完成度”放到了“从 0 原创”之前。
2. 语义不变量不足：没有在每次设计决定时追问“这还是不是从 0”。
3. 预先自我批判不足：能在用户指出后完美诊断，却没有在实施前自行发现。

这类问题在 Agent 任务中很常见：模型能把方案做得越来越完整，但完整度会让错误方向更难被察觉。

6. 用户纠偏后，K3 为什么明显变强了#

6.1 它的复盘不是泛泛道歉#

用户在 context.jsonl 第 399 行 指出问题后，K3 具体承认复用了：

• 固定玻璃导航。
• 左大字标 + 右头像 Hero。
• 数字 → 作品 → 写作 → 联系的章节顺序。
• 深色编辑感视觉。

它还重新定义了复用边界：

• 可复用的是数据注入、chrome={false}、双语 prop 等管道。
• 不该复用的是视觉语言和页面存在方式。

这是高质量自我纠错，因为它回答了三个问题：

1. 错在哪里。
2. 为什么会错。
3. 下一版哪些东西允许保留，哪些必须丢掉。

6.2 第二次给出的三个方向差异足够大#

K3 没有只给“换颜色”“换字体”“换动画”这种伪选项，而是给了三种完全不同的页面范式：

用户选择了“Agent 会话即主页”。这个选择非常关键，因为它不是给原页面换皮，而是改变“页面是什么”。

6.3 第二版把入场动画融入了页面本体#

第二版不再使用独立 Overlay。它的叙事变成：

1. 首屏只出现一条用户 Prompt：“介绍一下 joye。别念简历，讲点真的。”
2. Prompt 逐字输入后，页面自动滚向 Agent 回答。
3. Identity、头像和真实数据以 Thought / Artifact 的形式生成。
4. 左侧 Plan 随滚动逐步勾选。
5. 项目、产品、文章和笔记成为 Session 里的执行结果。
6. 最后把会话“交给访客”，输入 blog、notes、about、contact、github 可跳转。

对应代码：

• 开场输入与自动滚动：v3-engine.ts 第 64–85、218–257 行
• Plan Rail：v3-engine.ts 第 279–326 行
• 交互命令框：v3-engine.ts 第 332–378 行
• Session 主结构：V3Home.astro 第 239–480 行

这个改动解决了第一版最根本的问题：

第一次是“先看一个 Agent 动画，再进入作品集”；第二次是“整个作品集本身就是 Agent 的一次执行”。

因此，创意不再只存在于前 6 秒，而贯穿整个浏览过程。

6.4 但第二版也不是绝对意义上的“完全没有章节”#

K3 在交付说明中说“没有 hero、没有 portfolio 章节”。从视觉和交互范式看，这基本成立；但从底层信息架构看，代码仍然按以下顺序组织：

identity → numbers → work → writing → handoff

这与典型作品集的“自我介绍 → 证据 → 项目 → 内容 → 联系”仍然一致。

区别在于：

• 第一版复用了布局和叙事外观。
• 第二版只保留了作品集不可避免的信息职能，并重新发明了呈现语法。

因此，“与 V2 彻底无关”是略有夸张的说法；更准确的表述应当是：

第二版没有复用 V2 的可识别视觉骨架，但仍保留了一个个人 Landing Page 所需的核心信息顺序。

这不是缺点，反而说明完全从零不等于故意破坏信息可读性。

7. 第二版最终结果的独立评价#

7.1 做得好的地方#

设计概念统一#

Prompt、Thought、Plan、Artifact、Generated Stamp、Handoff 和可输入命令属于同一个视觉语言，不再是多个效果的拼盘。

内容真实而且动态#

• 文章数来自 Content Collection。
• Talks 数量来自真实集合。
• GitHub Stars 来自现有 Repo 数据与构建时获取。
• 中英文分别注入对应文章和 Notes。

例如中文路由的数据注入见 src/pages/v3/index.astro 第 15–57 行。

对多类受众的内容覆盖比较合理#

动画服务于叙事#

第二版的动画不是独立装饰：

• 打字代表 Session 输入。
• 自动滚动代表 Agent 产生回答。
• Blur → Sharp 代表 Artifact 生成。
• Plan 勾选代表任务推进。
• 数字滚动代表 Query Result。
• Handoff Prompt 让访客接管会话。

可访问性与降级意识较强#

• prefers-reduced-motion 下保留静态内容。
• 图片有 alt。
• 命令反馈使用 aria-live='polite'。
• 导航、主内容、Aside、Footer 的语义结构清楚。
• 英文和中文路由分别验证。

Scope 控制最终是干净的#

最终 Commit 只包含四个新文件，共 1,793 行：

src/components/v3/V3Home.astro   1280 lines
src/components/v3/v3-engine.ts    398 lines
src/pages/en/v3/index.astro         57 lines
src/pages/v3/index.astro            58 lines

没有修改 /、/en、/v2 和现有 Intro 组件。

7.2 仍然存在的不足#

“真的会话”其实是交互剧场#

页面没有连接真实模型；所谓 Live Prompt 只是五六个预定义命令的路由器。作为 Landing Page 这是合理的，但“会话真的交给你”略有营销化。

更准确的文案可以是“用命令继续探索”，避免访客误以为这是可自由对话的 Agent。

视觉语言仍然带有通用 AI Terminal 倾向#

深色、青色、等宽字、Prompt 和 Artifact 是很自然的 Agent 语言，但也已经是常见 AI 产品审美。真正让它属于 Joye 的部分，主要来自：

• 真实内容与数据。
• f/1.4 摄影细节。
• 个人金句。
• 项目与经历。

如果继续精修，可以让“Joye 的个人气质”再多一些，让“K3 的 Agent UI”少一点。

首屏有一定耐心成本#

首屏故意只显示一条 Prompt 和大量黑色留白，依赖打字与自动滚动建立戏剧性。动画成功时很有记忆点；如果用户立即滚动、浏览器性能差或 JS 失败，冲击力会下降。

此外，runIdentity() 会调用 scrollIntoView()。如果访客在打字结束前主动滚动，页面可能把他拉回 Identity。这是视觉演出与用户控制权之间的取舍。

主组件偏大#

V3Home.astro 有 1,280 行，混合了：

• 双语文案。
• 产品数据。
• 页面结构。
• 大量样式。
• 少量 Inline Script。

对实验性 Landing Page 可以接受，但如果未来提升为正式首页，应拆成 Copy/Data、Session Sections、Artifact Card 和样式层。

验证话术略有过度自信#

K3 在过程中说“全部章节完美”，最终说“交互 Prompt 是真的”。日志能证明它做了广泛验证，但不能证明页面“完美”，也没有真实用户测试、Lighthouse 或 Core Web Vitals 数据。

应该把“完美”改为“当前截图与自动检查未发现阻塞问题”。

第一版计划承诺项在 Pivot 后没有重新建立#

第一次计划提到 Lighthouse、主题验证、独立 Intro、Replay 等；第二版推翻方向后，没有写一份新的正式计划或新的验收矩阵。最终验证很丰富，但计划与现实之间已经漂移。

Todo 收尾时甚至仍保留了 V3Intro 相关表述，而该文件已经被删除。这反映出 Harness 的计划状态没有随着重大重构同步更新。

8. K3 的工程执行表现#

8.1 长程持续性：强#

这次任务跨越约 3 小时 19 分钟，并经历：

• Plan 模式。
• 三个子 Agent。
• 一次 StepInterrupted。
• 用户 continue。
• 用户实时纠偏。
• /yolo 权限模式变化。
• 完整推翻和重构。
• 最后独立的 Commit/Push 回合。

K3 没有在恢复后重新从头探索，也没有忘记分支、路由和双语约束。这说明模型与 Harness 的长上下文续接组合是有效的。

8.2 代码生成：强，但偏好大块写入#

第一次写出约 64.6 KB / 约 2,326 行；第二次最终交付 1,793 行。生成速度和结构完整性很强，但大块写入也直接产生了问题：

• 第二版 v3-engine.ts 一次写入时，属性选择器引号冲突导致多处语法错误。
• 随后的 sed 批量修复又因 Shell 引号错误失败。
• Check 又发现 GSAP Timeline callback 的 TypeScript 类型错误。

这些都被修复了，但说明 K3 更倾向“先写大块，再靠工具收敛”，而不是“小步编译”。

更稳健的节奏应该是：

页面骨架 → check
开场动画 → check + screenshot
一个 Artifact → check + screenshot
完整数据循环 → test
移动端/reduced-motion → build

8.3 调试推理：很强#

第一次入场动画出现 SVG Blueprint 样式异常时，K3 没有停在“改个颜色试试”，而是逐步检查：

1. 页面源 HTML 是否包含对应节点。
2. Vite 输出的 scoped style block 是否包含规则。
3. 浏览器当前 Session 是否指向正确页面。
4. 动态 SVG 节点能否匹配 Astro scoped CSS。
5. 源文件和浏览器拿到的 CSS 是否一致。
6. 是否存在 .vite / Astro 缓存污染。
7. 清缓存并重启 Dev Server后重新截图。

这是典型的假设驱动调试，而不是随机试错。

第二版移动端验证中，browser-use 视口行为不符合预期，它又依次尝试：

• Browser 工具内能力。
• 本机 Headless Chrome。
• Playwright Probe。
• 读取真实布局宽度、Overflow 和 reduced-motion 可见状态。

这种环境适应能力是本次 K3 最强的部分之一。

8.4 视觉验证：非常强，但成本高#

整个会话读取了 37 张截图。它验证了：

• 第一版入场的多个时间帧。
• 第一版 Hero、数字、作品、文章和 Outro。
• 第二版 Prompt、Identity、Numbers、Work、Writing、Handoff。
• 错误命令和成功跳转。
• 英文页。
• 390 px 移动端。
• reduced-motion 静态路径。

这比只跑 check 和 build 的前端 Agent 可靠很多。

代价是 37 张图片约占上下文 6.5 MB，并推动会话上下文持续膨胀。更好的 Harness 可以只保留关键帧、提取视觉差异摘要，或在完成一轮后压缩早期截图。

8.5 Git 行为：最终正确，中途有一个危险动作#

做得好的地方：

• 开始前检查工作区和当前分支。
• 按用户要求创建 feat/v3-landing。
• 未经请求时不提交。
• 用户明确要求后才 git add、Commit、Push。
• 最终只提交四个 V3 文件。
• 分支正确跟踪 origin/feat/v3-landing。

危险点：

• bun run format 格式化了全仓，制造 99 个既有文件修改。
• K3 随后用 git checkout -- . 清除它们。

本次因为它已经验证初始工作区干净，且 V3 文件仍是 Untracked，所以没有丢失用户修改；但作为通用 Agent 操作，这仍然危险。正确做法是从一开始只格式化目标文件，而 K3 在第二版才改为 scoped Prettier。

9. Prompt 符合度矩阵#

这里最重要的不是最终全绿，而是：

如果用户没有在 00:44 主动指出“像 V2”，K3 很可能会把第一版当成成功交付。

这说明它的验收主要覆盖了“代码和视觉是否运行”，没有覆盖“设计是否原创”这一语义验收项。

10. 从这次任务看，K3 的模型行为画像#

10.1 强项一：能把开放式 Repo 任务迅速结构化#

K3 不需要用户告诉它读哪些文件。它会主动识别：

• 人物内容。
• 路由与 i18n。
• 设计系统。
• 动画技术栈。
• 真实数据源。
• 测试与构建命令。

这类“从模糊创作要求到工程地图”的能力很强。

10.2 强项二：长程状态和工程上下文保持较好#

最终上下文达到约 253,803 tokens，但 K3 仍保持：

• /v3 和 /en/v3 的双语边界。
• noindex 的预览属性。
• 不修改正式首页。
• 使用现有 Repo 数据。
• reduced-motion。
• 最后只提交目标文件。

它在“长任务中不忘基本工程边界”方面表现不错。

10.3 强项三：反馈后的概念重构能力非常强#

它不是对第一版做局部修补，而是能够：

• 识别设计失败的结构原因。
• 重新定义合理复用边界。
• 生成三个本质不同的概念。
• 删除旧 Intro。
• 重新编排页面的存在方式。

这说明 K3 的创意能力不是不足，而是第一次被错误目标函数压住了。

10.4 弱项一：容易把“参考现有最佳实践”变成“依赖现有最佳答案”#

在工程任务中，阅读现有实现通常是优点；在原创设计任务中，它可能造成强烈锚定。

K3 没有自动区分：

• “学习 V2 的技术模式”。
• “避免 V2 的设计答案”。

这是最值得沉淀的模型使用经验。

10.5 弱项二：语义验收弱于机械验收#

它很会检查：

• 类型是否通过。
• 测试是否通过。
• Build 是否成功。
• 页面是否渲染。
• 动画是否出现。
• 移动端是否 Overflow。

但第一次没有检查：

• 页面是否仍然像 V2。
• “从 0”是否贯彻到信息架构。
• 四类受众的第一印象是否真的不同。
• 页面是否只是“效果多”，而不是“叙事原创”。

也就是：

K3 的验证系统偏可执行断言，缺少高层语义断言。

10.6 弱项三：计划在重大 Pivot 后容易失效#

第一版计划非常详细，但用户纠偏后：

• 没有重写计划。
• 没有重新列新的验收项。
• Todo 中仍残留已删除的 V3Intro。
• 最终交付话术只能靠模型记忆重新总结。

这说明 K3 能重构代码，却不一定会同步重构自己的外部状态表示。

10.7 弱项四：过度完成会放大返工成本#

第一版并不是早期草图，而是已经：

• 写了约 2,326 行。
• 跑完 Check、Test、Build。
• 做了多帧 Intro 截图。
• 调试了 SVG 和 Vite CSS。
• 检查了完整滚动章节。

此时才发现方向错误，说明 K3 的默认策略更像“快速把一个方向做完整”，而不是“低成本验证方向”。

对于设计任务，应该先做概念验证，再做工程验证。

10.8 弱项五：表达有时比证据更自信#

典型表述包括：

• “全部章节完美”。
• “与 V2 彻底无关”。
• “输入框是真的”。

它们有事实基础，但不够校准。K3 更适合用：

• “当前自动检查和截图未发现阻塞问题”。
• “未复用 V2 的可识别视觉骨架”。
• “输入框支持预定义导航命令”。

11. Kimi CLI Harness 在本任务中起了什么作用#

虽然本报告聚焦 K3，但模型表现不能脱离 Harness。

11.1 Harness 放大了 K3 的强项#

11.2 Harness 也放大了问题#

• 子 Agent 的长报告把 V2 变成极强的上下文锚点。
• Plan 一旦批准，Harness 更偏向执行，而不是继续挑战方案。
• 没有“重大需求纠偏后自动使旧 Plan 失效”的机制。
• Todo 不会自动校验文件是否仍存在。
• 浏览器截图以大体积 Base64 进入上下文，造成高成本。
• Shell 权限足够大，因此全仓格式化和 git checkout -- . 这类动作可以直接发生。

因此，本次最值得给 Harness 增加的能力不是更多工具，而是两个 Gate：

1. 设计原创性 Gate：实施前对现有页面做结构相似度审查。
2. Pivot Gate：用户否定核心方向后，旧 Plan 和 Todo 自动标记失效，必须重新规划。

12. 量化数据：K3 为这次任务付出了多少执行成本#

以下数字来自完整日志解析。

12.1 调用与工具规模#

12.2 Token 与上下文#

按本地分析脚本采用的价格假设，整个会话的 API 等价成本约为 9.58 美元；Landing Page 任务约为 9.47 美元。这只是估算，不是 Kimi 实际账单。

值得注意的是：

• 第一版 105 次调用，估算约 5.07 美元。
• 纠偏后只有 52 次调用，但估算约 4.41 美元。

第二版调用数只有第一版的一半左右，成本却接近第一版，因为此时每一步都需要携带和读取已经非常长的上下文。

这说明：

越晚发现方向错误，Agent 返工不仅浪费代码时间，也会显著放大长上下文成本。

12.3 延迟#

Root 模型步骤延迟：

• P50：约 35.6 秒。
• P90：约 135.3 秒。
• 最大：约 737.5 秒。

子 Agent P50 约 16.6 秒。三个 Agent 并行启动，因此它们虽然各自运行数分钟，但减少了串行等待时间。

对“长程自主完成”而言，这些延迟可以接受；对人机高频协作而言，K3 的某些超长思考步骤会显得明显迟钝。

13. 哪些做法值得学习#

13.1 调研拆成“人、产品、系统”#

这是本次最值得复用的框架：

• 人：我在为谁设计？这个人有什么独特故事？
• 产品：页面在哪、服务谁、数据从哪来？
• 系统：Repo 允许我用什么技术？有什么规范？

13.2 只问真正改变边界的问题#

用户已经授权模型选风格，K3 没有重新问风格偏好，只确认落地路由。这个问题质量高。

13.3 用真实数据而不是硬编一个 Portfolio#

文章、Notes、Talks、Repo Stars 都来自现有数据源。页面因此不是一个孤立 Demo，而是博客的一部分。

13.4 把个人身份转换成设计隐喻#

K3 能从“Agent 工程师、摄影、build in public、系统思维”提取：

• Agent Session。
• Thought Stream。
• Artifact。
• f/1.4 显影。
• Plan 推进。
• Handoff。

这比直接套“赛博朋克”“极简”“玻璃拟态”更有品牌相关性。

13.5 视觉任务必须看真实页面#

它不仅构建页面，还看入场帧、滚动段落、移动端和 reduced-motion。对于前端 Agent，这一点应当成为默认流程。

13.6 用户纠偏时具体承担，不抽象道歉#

K3 的“我不辩解 + 列出具体复用骨架 + 重新定义合理复用边界”是非常好的反馈处理范式。

13.7 Commit/Push 权限边界清楚#

用户只要求建分支时，它没有擅自提交；用户明确要求后才 Commit 和 Push。

14. 哪些问题应该沉淀成反模式#

14.1 反模式：让“最强现有实现”主导原创任务#

如果任务关键词是“从 0”“全新视觉语言”“不要像旧版”，现有页面只能作为：

• 技术约束参考。
• 禁用清单来源。
• 相似度检查对象。

不应作为创意起点。

14.2 反模式：新文件等于新设计#

新建组件、新写 CSS、新写 GSAP，并不代表设计是新的。应分别审查：

• 代码来源。
• 布局骨架。
• 信息架构。
• 视觉语言。
• 动效隐喻。
• 叙事节奏。

14.3 反模式：只出一个概念就直接全量实现#

开放式设计任务至少应先有三个差异足够大的概念，再选一个做首屏原型。

14.4 反模式：把效果做完再请用户看#

第一次用户看到问题时，K3 已经投入 100 多次模型调用。应该在以下节点提前曝光：

1. 人物理解摘要。
2. 三个创意方向。
3. 首屏静态稿或 Storyboard。
4. 10–20 秒入口原型。
5. 再做全页。

14.5 反模式：全仓格式化后再恢复#

始终只格式化目标文件。不要依赖 git checkout -- . 补救。

14.6 反模式：重大 Pivot 后继续沿用旧 Plan#

核心概念被用户否定后，应立即：

• 将旧 Plan 标记废弃。
• 写一份短的新 Plan。
• 重建 Todo。
• 重新列验收矩阵。

14.7 反模式：用“完美”替代证据#

交付陈述应报告：

• 验证了什么。
• 没验证什么。
• 哪些是自动检查。
• 哪些是模型视觉判断。
• 哪些仍需真实用户反馈。

15. 如果重做一次，理想的 K3 工作流#

Phase 1：把 Prompt 转成内部任务合同#

必须：新分支、/v3 + /en/v3、Landing、入场动画、真实内容、多受众
核心不变量：不能复用 V2 的可识别视觉骨架与叙事结构
允许复用：数据、路由、token、依赖、图片素材、工程模式
成功标准：5 秒记住、30 秒理解本人、完整浏览后有明确下一步

Phase 2：隔离式调研#

• Agent A：只研究 Joye 与内容，不看现有 Landing。
• Agent B：只研究工程和路由，不给设计建议。
• Agent C：研究 V2，并输出“禁止复用特征清单”。
• Agent D：模拟四类受众。

Phase 3：先产出三个概念#

每个概念必须包含：

• 一句话隐喻。
• 首屏构图。
• 入场 0–6 秒 Storyboard。
• 全页滚动逻辑。
• 与 Joye 的独特关联。
• 与 V2 的差异。
• 性能和移动端风险。

Phase 4：原创性 Gate#

对每个方案评分：

任何“与 V2 结构差异”低于 8/10 的方案不得进入编码。

Phase 5：只做首屏和入场原型#

先实现：

• 首屏。
• 入口动画。
• 一个代表性 Artifact。
• 390 px 移动端。
• reduced-motion。

截图和用户确认后，再扩展完整页面。

Phase 6：增量实施#

每完成一个块就：

• 格式化目标文件。
• check。
• 截一张关键图。
• 和任务合同对照。

Phase 7：双重验收#

工程验收：

• Check。
• Test。
• Build。
• Desktop / Mobile。
• zh / en。
• reduced-motion。
• 交互命令。

语义验收：

• 是否仍能一眼看出 V2 骨架？
• 5 秒内是否知道 Joye 是谁？
• HR 是否能找到可信证据？
• 技术面试官是否能看到工程深度？
• 普通读者是否知道下一步点什么？
• 动画是否服务叙事，而不是延迟内容？

16. 一个更适合交给前端 Agent 的升级版 Prompt#

用户原 Prompt 已经不错。下面这版不是为了替用户承担模型缺陷，而是把本次经验沉淀成可复用任务合同：

当前 repo 是我的个人博客。请创建一个新分支，为博客从 0 设计并实现一套新的 Landing Page 和对应的入场动画，用来展示你的前端创作与工程能力。

这里“从 0”有明确含义：
- 可以复用现有数据、路由/i18n 管道、设计 token、依赖和图片素材；
- 不允许复用现有首页或 V2 的可识别布局骨架、章节编排、Hero 构图、导航形态和主要动效隐喻；
- 新页面必须从我的人物、内容和目标受众重新推导视觉语言和信息架构。

我不会指定赛道或风格。请主动阅读我的代码、文章、Notes、项目和 About，理解我是谁，再自行选择最合适的方向。

目标受众包括读者、粉丝、HR 和技术面试官。成功标准是：
- 5 秒内产生记忆点；
- 30 秒内理解我是谁以及我与其他候选人的差异；
- 浏览后愿意继续进入博客、项目、About 或联系页面。

编码前请先输出：
1. 你对我的人物与品牌理解；
2. 现有 V2 的“禁止复用特征清单”；
3. 三个本质不同的创意方向；
4. 每个方向的 0–6 秒入场 Storyboard、全页叙事、受众价值和工程风险；
5. 你推荐的一个方向，以及它为何不是 V2 的变体。

方向确认后，先做首屏 + 入场的小原型并截图验证，再实现全页。最终需要验证中英文、桌面、移动端、reduced-motion、交互、check、test 和 production build。只修改本任务需要的文件；不要全仓格式化；未经我明确要求不要 commit 或 push。

这版 Prompt 最重要的增加项不是更多细节，而是：

把“合理复用”和“禁止复用”明确分层，并把原创性审查放在编码之前。

17. 最终判断：K3 在这个任务上到底表现如何#

如果只看最终 Commit，K3 的表现很好：

• 做出了概念统一的 Agent Session Landing。
• 页面与 Joye 的 Agent 身份和真实内容关联紧密。
• 双语、移动端、reduced-motion、交互、测试和构建都得到验证。
• Git Scope 干净，最终按授权提交和推送。

如果看完整过程，则评价需要更严格：

• 它第一次没有守住“从 0 设计”这个最重要的语义约束。
• 它被自己调研出来的 V2 强参考物锚定。
• 它缺少实施前的原创性 Critic。
• 它直到用户指出后，才把自己本来具备的批判与创意能力释放出来。
• 它为错误方向投入了大量代码、截图、调试和上下文成本。

所以这次任务揭示的 K3，不是一个“第一次就总能选对方向”的模型，而是一个：

研究能力强、工程执行强、视觉调试强、长程恢复强；但在开放式创意任务中容易向现有高质量实现收敛，需要显式原创性约束或外部 Critic；一旦获得具体反馈，又能进行非常强的结构级自我纠错。

对实际使用者而言，最有效的用法不是把所有要求写得无限详细，而是给 K3 加三个关键检查点：

1. 编码前列出“允许复用 / 禁止复用”。
2. 单一方向实施前先比较三个真正不同的概念。
3. 完整实现前做一次独立的语义与原创性审查。

如果加上这三个 Gate，K3 在这类 Landing Page 任务中的有效产出率会显著高于本次日志表现。

附录 A：最终交付状态#

• 分支：feat/v3-landing
• Commit：038f298 feat(home): add v3 agent-session landing page
• 远端：origin/feat/v3-landing
• PR 创建入口：https://github.com/joyehuang/blog/pull/new/feat/v3-landing ↗
• 文件：4 个新文件，1,793 行新增
• 当前本地状态：分支与远端同步，工作区干净
• Kimi 日志中的最终验证：
  • Astro Check：0 errors / 0 warnings / 0 hints
  • Tests：24 pass / 0 fail / 288 assertions
  • Production Build：Exit 0
  • /v3/index.html 与 /en/v3/index.html 均成功生成

附录 B：关键证据索引#