说说从这个项目上学到的经验和教训吧:
1. 以后绝对不接这种项目,无法拓展,无法复用;
2. 接项目之前必须要有明确的需求文档。我们反复问客户要需求文档,一直说没有,然后预览的时候提一大堆要求,我们只能根据这些反馈生成需求文档。过了几周之后,才给了一个成型的文档,聊胜于无吧;
3. 哪怕是非代码项目也尽量用代码的思路来迭代,这样可以构建一些工具来提高效率,然后可以在此基础之上生成一些 skill,省得反复手敲 prompt;
4. 把 CI / CD 的思路也引入进去,这样可以一直迭代。本来客户要求用 ppt 预览,第一次效果很差,我们建议后面直接给 html。发去文件之后,他们的浏览器又不能渲染。最后选择了 cloudflare pages + zero trust access 构建了一套线上预览系统,限制用指定邮箱访问,这样他们只要用邮箱接收验证码就能看到最新版本;
5. 预算之内,能用钱买到的 SaaS 服务就不要自己重造轮子。客户要求能在线上预览里标注,找了一圈,我们选了 bugherd,比我们想象得好用的多。只要多加一个按钮,用户可以在上面的的网页自由标注,我们可以从 bugherd 上看到这些 ticket,直接从它的 API 里读到反馈,然后丢给 agent 改,改完之后标注 ticket 完成,我们可以再次发布。整个过程我们可以不用登陆 bugherd 后台。要是自己写这个轮子,或者部署开源的方案都耗费精力。
6. 写了一套按照内容生成流程图 svg 的工具,这样这些流程图就不用走 AI 生成的路了,可以大大节省 token 的消耗。
7. 和搭档之间的合作也尽量走 agent ,这样可以大大太高效率。比如共用 一套 skills,让 agent 生成各种另外一个 agent 可以读懂的文档。
Post #691
690
DPS Build 前阵子,为了现金流,接了一个与核心业务完全不相干的活,现在后悔不已。 核心业务已经搭好了工具库,有项目进来就可以上手,有些个例需要临时休整一下,可以同时接好几个项目,所以整体来说比较容易拓展。 这个不相干的活处处都是雷: 1. 每一个子项目都要按需抓取数据,而且是从不同的网站抓,能不能抓得到还是未知数; 2. 设计大量前端设计,客户非科技行业,非产品经理,无法提供详细量化目标; 3. 要用到的工具库非常小众,需要花大量时间试错。 4. 最要命的是这种项目几乎是一次性的,不太可能再有类似的需求。…
- 👍 4
- ❤ 1