面对需求变化时控制返工的内容工作流:从越界修改到可验收
从“面对需求变化时控制返工”出发,给内容工作流建立证据、评审和回退边界,避免越界修改被表面完成度掩盖。
Posts
Start discussions like a forum — great for questions, opinions, tool recommendations, and experience sharing.
从“面对需求变化时控制返工”出发,给内容工作流建立证据、评审和回退边界,避免越界修改被表面完成度掩盖。
把修复只在真实浏览器出现的问题作为讨论入口,说明测试生成为什么需要逐文件差异,以及生成结果看起来正确却无法运行出现后怎样缩小影响范围。
针对数据库迁移在“从失败日志定位根因”里的落地问题,本文用健康端点与依赖状态检查越界修改,并邀请社区比较不同取舍。
组里最近来了几个 Vibe Coding 重度用户,PR 一个接一个,功能确实快。但打开一看,测试覆盖率不升反降,好几个 PR 全是生成代码零测试。 我提了 review 意见让人补测试,对方说"AI 写的代码我看过逻辑没问题"。这话我听着就慌,过了两个月谁还记得逻辑。 大家团队
翻了下我一年前的笔记,那会儿 Claude Code 还只是个能跑命令的 CLI,体验挺糙的。现在 plan 模式、subagent、任务拆分、并行调用一堆东西堆上来,已经完全不是我认识那个工具了。 最直观的感受是长任务能跑完了,以前动不动就断,现在让它一口气改十几个文件再跑测试
先声明不是踩 Cursor,工具本身很好,是我自己用不动。 我大部分工作是小修小补和读代码,Composer 的多文件改动对我反而是负担,每次都要仔细 diff 它改了啥。而 Copilot 的行内补全 + Chat 已经够我用了,关键是便宜不少,还能跟我现有的一堆 VS Cod
上周第一次正经用 AI 写完一个小工具,记录几条新手血泪教训,希望能帮到刚入坑的人。 一是别一上来就让它写整个项目,先从一个函数、一个组件开始,验证它的输出风格你 hold 得住。二是描述需求要带约束(用什么库、返回什么结构),不然它默认的选择经常很离谱。三是改完立刻跑,别攒着一
用了一周 Cursor 的 Tab 补全,确实比 Copilot 胆子大,经常能猜到我接下来好几步要写啥,多行预测也挺准。但误触的成本也高,一不留神就接受了不该接受的。 Copilot 走的是稳路线,补全偏保守,胜在几乎不添乱。 我现在写新代码用 Cursor Tab,改老代码切
听起来有点反直觉,但这是我今年的真实感受。以前手写代码,review 更多是挑风格、命名小问题;现在 AI 写的代码表面光鲜,逻辑漏洞、安全坑、性能问题都藏得深。 我现在 review 会特别盯三点:边界条件有没有覆盖、是不是引入了不必要的依赖、错误处理是不是"假装处理"(cat
经常遇到这种情况:让它跑个稍长的任务,前几分钟好好的,然后突然就停在那不动,也不报错,按回车也没反应。 试过 Ctrl+C 重来,但之前的进度全没了,挺崩溃的。网络应该没问题,别的命令都正常。 有没有什么排查思路或者参数能调?比如超时设置、断点续跑之类的。先谢了。
就一个很小的空指针问题,我让它"修一下这行可能的 null",结果它觉得"这个文件结构不太对",自作主张把 200 行重排成 350 行,命名风格也全换了。 diff 一打开我都傻了,根本没法 review。最后只能 reset 自己手改那两行。 后来我在 prompt 里加了"
分享下我现在的日常流程,不一定最优,但用着顺手。 新功能先让它在 plan 模式下出方案,我确认后再 apply;Server Action 这种容易出错的,强制它先写一个测试用例再写实现;样式部分我手写,不让它碰 Tailwind 类名(它审美不太行)。 最后一步永远是跑 pn