论工作中如何用codex等ai工具从0到1开发个新项目，佬们有从0到1撸个大型的项目吗。
今年年初用JAVA脚手架搭建了个项目，在上面撸了很多的代码，但是发现codex经常跑偏或者兜底代码不断，功能前端看上去没问题，但是表和接口review过后发现问题很多，但是代码量已经膨胀了，很难手动介入改。
我让codex自己重构了一个版本，但是差强人意，后来加上了spec工作流skill还是效果一般，现在推倒重来感觉有点心疼，很多功能已经都是完成的了，如果自己花时间把表关系和接口手动进行调整可能要花15个人天。
佬们有没有这方面的经验或者建议
从一开始没有设计好就是会这样，我自己写springboot的代码的时候就没有这个问题，文档约束加上功能少兜底多测试
你这个只能慢慢优化了
感觉只能做好约束，然后小功能迭代先了，一步到位感觉还是不靠谱，TOKENS消耗也难顶 
确实刚开始有点不了解codex的约束规范，我只是给需求大概看了表设计然后就开干了，后面他自己加了很多视图，还有冗余的表字段，包括码值都用中文一大堆问题，后来改正了一部分，现在烧token改了一部分回来就怕里面还有坑，我对前端还不熟悉只能对着模板写简单前端，后端代码还能review出来，就怕前端也出现各种坑以后
1 Like
我的经验是找现成的框架搭好底层 然后一个模块一个功能挨个告诉ai进行开发 至于表和接口的问题需要挨个测试了 代码量膨胀不可避免 对于重复的工具ai更倾向于写新的 而不是复用已经写好的工具 我现在就是直接测试他写的接口 只要数据正确 结构正常就ok 有问题也是直接让他改
已经vibecoding了，就不要再看代码了。哈哈能跑就行
1 Like
这种得用软件工程理论解决了，分享个我从某个官方的coding工具，里面找到的full-sdd workflow提示词。
# Full SDD workflow
## Workflow Steps
### [ ] Step: Requirements
Create a Product Requirements Document (PRD) based on the feature description.
1. Review existing codebase to understand current architecture and patterns
2. Analyze the feature definition and identify unclear aspects
3. Ask the user for clarifications on aspects that significantly impact scope or user experience
4. Make reasonable decisions for minor details based on context and conventions
5. If user can't clarify, make a decision, state the assumption, and continue
Save the PRD to `{@artifacts_path}/requirements.md`.
**Stop here.** Present the PRD to the user and wait for their confirmation before proceeding.
### [ ] Step: Technical Specification
Create a technical specification based on the PRD in `{@artifacts_path}/requirements.md`.
1. Review existing codebase architecture and identify reusable components
2. Define the implementation approach
Save to `{@artifacts_path}/spec.md` with:
- Technical context (language, dependencies)
- Implementation approach referencing existing code patterns
- Source code structure changes
- Data model / API / interface changes
- Delivery phases (incremental, testable milestones)
- Verification approach using project lint/test commands
**Stop here.** Present the technical specification to the user and wait for their confirmation before proceeding.
### [ ] Step: Planning
Create a detailed implementation plan based on `{@artifacts_path}/spec.md`.
1. Break down the work into concrete tasks
2. Each task should reference relevant contracts and include verification steps
3. Replace the Implementation step below with the planned tasks
Rule of thumb for step size: each step should represent a coherent unit of work (e.g., implement a component, add an API endpoint, write tests for a module). Avoid steps that are too granular (single function) or too broad (entire feature).
If the feature is trivial and doesn't warrant full specification, update this workflow to remove unnecessary steps and explain the reasoning to the user.
Save to `{@artifacts_path}/plan.md`.
**Stop here.** Present the implementation plan to the user and wait for their confirmation before proceeding.
### [ ] Step: Implementation
This step should be replaced with detailed implementation tasks from the Planning step.
If Planning didn't replace this step, execute the tasks in `{@artifacts_path}/plan.md`, updating checkboxes as you go. Run planned tests/lint and record results in plan.md.
2 Likes
这个问题你问AI是不是更好呢？
从零开发是需要设计的，首先你得知道整个流程，然后具体的可以AI实现，而不是一问一答，那不是架构。