用 AI 做项目，怎么避免”屎上雕花”？

基本信息

• 作者：岚天（AI 产品经理，AI 行业资深从业者）
• 来源：人人都是产品经理（woshipm.com）
• 日期：2026-09-09
• 阅读时长：约 18 分钟

核心观点

当七八成工作交给 Agent 后，产品经理（项目负责人）的核心价值转向「规划与判断」。文章以预约工具为例，剖析如何打好项目「地基」：明确目标、场景、规则与验收，避免在错误方向上”屎上雕花”（成果越做越完整，最初想解决的问题却未必更清楚）。

1. 别把没想清楚的事做完整

“做个预约系统”只是给产物起了个名字；“让前台确认一个真实可约的时段，减少安排冲突”才把目标往前推了一步。文章提出「地基」的四个具体问题：

• 为谁解决什么问题
• 一次真实任务怎么完成
• 哪些规则不能靠猜
• 拿什么结果验收

一个可写出的检查场景：同一员工的同一时段，两个人同时预约，只能确认一单。有了这些答案，才有依据讨论一个功能值不值得加、一个方案应不应该改。

2. 先把不能靠猜的事找出来

开工前不可能知道所有答案，但要把三种东西分开：已经确认的事实、需要验证的假设、现在要做出的决定。

沿用预约工具例子：

• 「前台需要代约」——向使用者核实过，才是事实
• 「先不考虑房间也能用」——是待验证的假设
• 「首版只供前台使用」——是主动做出的范围选择

三种东西如果写成一份口气很确定的需求文档再让 AI 照做，假设就可能一路被当成事实用下去。不知道的事不必硬猜，可以变成一项验证任务，但要说明验证结果出来后会影响哪个决定。

3. 任务要连验收一起交代

任务里除了”做哪个模块”，还要有输入、交付物和检查方法。先挑一条重要任务从头走到尾：预约工具可以先只有一种服务、一个员工角色，但至少要能查空档、提交预约、看到确认结果，再取消并释放时段。

作者引用了 Anthropic 2025 年长任务开发实验的记录：做太多、过早宣布完成、缺少端到端验证是常见问题，可用逐项推进和交接记录改善。[3]

4. 别拿”再改一下”硬撑

把反馈写成三件事：发生了什么，原本应该怎样，改完怎么核对。例如：

“同一员工的 10:00 出现两单，预期只能确认一单。请定位原因，说明影响哪些地方。修复后重试同一场景，再检查取消与释放时段。”

比”预约有点问题，再优化一下”多不了多少字，却有了可以查、可以改、可以复验的具体事情。要判断是否回头重想方案，检查三处：原来的前提还成立吗？同类问题是不是在不同地方反复出现？兼容这条新要求需要动到多少相关部分？

5. 运行成功，还得有人愿意用

“完成”要拆开看：页面能打开是一件事；正常、冲突和取消场景都按规则工作是另一件事；实际使用者能不能独立完成任务，还要再检查一次。让 AI 评价自己的成果、再让另一个 AI 说”不错”，仍然没有走完这一环——实际使用效果需要回到人和工作现场。

6. 执行交出去了，判断靠什么

规划不必全由人独自完成：整理背景、比较方案、提出反例、运行检查，都可以让 AI 参与。但目标和规则由谁确认、几个方案怎么取舍，仍然需要项目负责人拿出依据。

实操内容保留

文章提供了一套与 AI 协作的实操方法，包含可复用的 Prompt 模板：

让 AI 参与规划（开工前，先别急着要页面）：

“先根据现有资料，还原使用者完成任务的全过程。把已确认事实、你的推测和缺失信息分开列出。给出两个首版方案，说明各自保留什么、暂时不做什么，以及最先需要验证的条件。先不要生成完整页面。”

交办任务时（把”帮我把预约功能做好”改成）：

“这一轮完成前台预约与取消，沿用已经确认的规则。交付可操作版本，并实际检查正常预约、重复占用、取消后释放时段。说明每项检查怎样做、结果是什么；没有验证的项目单独列出。”

修 bug 反馈模板（三件事）：

“同一员工的 10:00 出现两单，预期只能确认一单。请定位原因，说明影响哪些地方。修复后重试同一场景，再检查取消与释放时段。”

研究报告的验收方式：除了要求 AI 列建议，还要让它交代每项建议的来源、最强的反对证据，以及哪条信息改变后需要重新排序。

需要留下来的状态记录：一份当前说明，保留有效规则、关键决定和待解决的问题，同时更新已经作废的要求——不必每次写长总结。Anthropic 的上下文工程文章也介绍了把进度和关键信息保存在对话之外、需要时再读取的做法。[2]

关键概念

• 屎上雕花：比喻项目卡在错误方向上，再补功能也补不到问题上，需要回头看一眼基础。
• 地基四问：为谁解决什么问题 / 一次真实任务怎么完成 / 哪些规则不能靠猜 / 拿什么结果验收。
• 事实 / 假设 / 决定三分法：已确认事实、待验证假设、现在要做的决定。
• 验收式任务交付：任务里带输入、交付物、检查方法，AI 知道要交什么，人也有地方下手检查。
• 反馈三件事：发生了什么、原本应该怎样、改完怎么核对。

与其他素材的关联

• 与主题「AI 时代产品经理」「AI Agent 协作」密切相关，可与多篇 woshipm 的产品经理 AI 协作素材对照。
• 引用了 Anthropic 的系列文章（Building effective agents、Effective context engineering、Effective harnesses for long-running agents），与 Agent 工作流相关素材构成交叉视角。

原文精彩摘录

“说得直白一点，就是”屎上雕花”。这个词不好听，但它很适合提醒我们：有些项目卡住，需要回头看一眼基础。再多补几个功能，可能也补不到问题上。”

“把七八成的执行交出去以后，留给自己的那部分工作，更不能含糊：知道为什么做，知道凭什么说做好了，也能在方向不对的时候停下来。下次想对 AI 说”继续优化”之前，可以先问一句：这次是在修一个明确的问题，还是在绕开一个需要重新考虑的决定？”

“让 AI 评价自己的成果，再让另一个 AI 说一遍”不错”，仍然没有走完这一环。实际使用效果需要回到人和工作现场。“

资料来源

• [1] Anthropic，Building effective agents，2024-12-19（本文仅引用 Agent 工作方式的说明）
• [2] Anthropic，Effective context engineering for AI agents，2025-09-29（用于说明跨轮次的信息维护）
• [3] Anthropic，Effective harnesses for long-running agents，2025-11-26（引用的是该文特定开发实验的观察，不作为所有模型与项目的普遍结论）

相关页面

（暂无）