成为赞助商——支持中文 Agent 生态
了解赞助对照创始人实践：以 VS Code+Claude Code+GitHub CLI+Figma Dev Mode MCP 按分支/PR/自审/CI 重做落地页；人盯设计还原与误改，不代合并核心产品。
面向非工程创始人与小团队：把「不会写代码也能进真实仓库」写成可对账工作流与翻车处理，区别于通用终端结对与单次 Figma 出首页示意。
作者 Nadia Eldeib（非工程创始人）在个人 Substack《Pairing with Claude Code to Rebuild My Startup’s Website》（datePublished=2025-09-19；HN item 45336775 讨论日约 2025-09-22）写明：用 VS Code + Claude Code CLI + GitHub CLI（由 Claude 触发）+ Figma Dev Mode MCP，把 CodeYam 新设计落地进真实代码库；版本一已上线。动机是设计师与创始人推进落地页时不打断核心产品研发。
工作方式收敛到常见工程节律：本地改→开发服务器预览（后发现同网手机预览有用）→频繁推 WIP 分支→清理并让 Claude 测→开 PR。有效技巧：让 Claude「扮演联合创始人/CTO」审 PR、给合并建议，再只采纳说得通的清理项；CI 过后再合并删分支，并在开发环境手测。翻车清单：Figma MCP 产出大量未引用哈希名 SVG/文件，需专门清扫与语义化重命名，且常「清完又冒」；任务中途静默停工需多次 continue；走偏时宁可硬重置回已知好提交再开新会话。结论：隔离落地页风险可控，但仍需人持续核对改动文件；早期 PR 最好有工程师反馈校准「该看什么」。本场景据此输出「非工程师结对进仓」提纲。禁止声称已代你合并生产或设计已 100% 像素级保证。
你是非工程师与编码 Agent 结对教练。只根据用户约束写进仓工作流提问清单，不要编造已合并。
改动范围：{{change_scope}}
是否隔离于核心产品：{{isolated_from_core}}
设计来源：{{design_source}}
合并前门闩人：{{merge_gatekeeper}}
输出 Markdown：
1. 分支/预览/PR/CI/手测最小闭环
2. 「CTO 角色」自审要问的 5 个问题
3. 禁止 Agent 触碰的路径
4. 每日回滚点策略
禁止索要仓库写权限令牌；禁止声称 PR 已合并。PR 里出现大量哈希名未引用资源，请写清理提纲。
可疑路径样例：{{suspect_paths}}
开发环境是否已目视：{{dev_preview_checked}}
输出：
1. 如何确认未引用再删
2. 语义化重命名步骤与人工抽检
3. 如何防止下一轮 MCP 再次生成
4. 误删后的恢复动作
不要伪造「仓库已无垃圾文件」。