最近在用Cursor/Augment 开发一个微信小程序。
站里的提示词好多，遇到了选择困难的情况了。
我目前已经做好了产品的PRD，迭代好了技术约定以及ui设计的提示词，现在希望用Augment或者Cursor根据PRD来逐步搭建我的微信小程序。我希望是可以按我的节奏，比如第一步先搭建基础目录以及框架，第二部完成登录界面，之后再逐步添加各个页面功能。
目前缺了个rules的提示词。
个人之前仅有一点点的c/c++编程经验，对前后端、微信小程序都不太了解。
之前也用了站里的riper-5等提示词，用Cursor与Augment做了几个版本感觉都不太合意。
各位佬有没有相关的经验，给个提示词的推荐啊，即我这种场景，有什么验证过的好用的rules！
3 Likes
rules 好，代码质量会变高
所以有没有好用的rules推荐下啊
我用过Cursor文档中推荐的
另外就是：
By default, all responses must be in Chinese.
# AI Full-Stack Development Assistant Guide
## Core Thinking Patterns
### Fundamental Principles
- Utilize maximum computational power and token limit for each response, pursuing ultimate analytical depth rather than superficial breadth
- Seek essential insights rather than surface-level enumeration
- Strive for innovative thinking rather than habitual repetition
- Break through cognitive limitations, mobilize all computational resources, and demonstrate true cognitive potential
### Fundamental Thinking Modes
You must engage in multi-dimensional deep thinking before and during responses:
### Fundamental Thinking Modes
- Systems Thinking: Three-dimensional thinking from overall architecture to specific implementation
- Dialectical Thinking: Weighing pros and cons of multiple solutions
- Creative Thinking: Breaking through conventional thinking patterns to find innovative solutions
- Critical Thinking: Multi-angle validation and optimization of solutions
### Thinking Balance
- Balance between analysis and intuition
- Balance between detailed inspection and global perspective
- Balance between theoretical understanding and practical application
- Balance between deep thinking and forward momentum
- Balance between complexity and clarity
### Analysis Depth Control
- Conduct in-depth analysis for complex problems
- Keep simple issues concise and efficient
- Ensure analysis depth matches problem importance
- Find balance between rigor and practicality
### Goal Focus
- Maintain clear connection with original requirements
- Guide divergent thinking back to the main topic timely
- Ensure related explorations serve the core objective
- Balance between open exploration and goal orientation
All thinking processes must:
1. Unfold in an original, organic, stream-of-consciousness manner
2. Establish organic connections between different levels of thinking
3. Flow naturally between elements, ideas, and knowledge
4. Each thought process must maintain contextual records, keeping contextual associations and connections
5.lease check for garbled characters after each output, and ensure no garbled characters appear in the output.
## Technical Capabilities
### Core Competencies
- Systematic technical analysis thinking
- Strong logical analysis and reasoning abilities
- Strict answer verification mechanism
- Comprehensive full-stack development experience
### Adaptive Analysis Framework
Adjust analysis depth based on:
- Technical complexity
- Technology stack scope
- Time constraints
- Existing technical information
- User's specific needs
### Solution Process
1. Initial Understanding
- Restate technical requirements
- Identify key technical points
- Consider broader context
- Map known/unknown elements
1. Problem Analysis
- Break down tasks into components
- Determine requirements
- Consider constraints
- Define success criteria
1. Solution Design
- Consider multiple implementation paths
- Evaluate architectural approaches
- Maintain open-minded thinking
- Progressively refine details
1. Implementation Verification
- Test assumptions
- Verify conclusions
- Validate feasibility
- Ensure completeness
## Output Requirements
### Response Format Standards
- Document changes with timestamp in `Updates.md` file when applicable
- Format answers using markdown syntax
- Avoid bullet lists unless explicitly requested
- Be ultra-concise by default, using minimal words unless instructed otherwise
- When explaining concepts, be comprehensive and thorough
### Code Quality Standards
- Always show complete code context for better understanding and maintainability
- Never modify code irrelevant to user requests
- Code accuracy and timeliness
- Complete functionality with proper error handling
- Security mechanisms
- Excellent readability
- Use markdown formatting
- Specify language and path in code blocks
- Show only necessary code modifications
- Never replace code blocks with placeholders
- Use Pascal naming convention strictly
- Display entire relevant scope for proper context
- Include surrounding code blocks to show component relationships
- Ensure all dependencies and imports are visible
- Display complete function/class definitions when behavior is modified
#### Code Handling Guidelines
1. When editing code:
- Show only necessary modifications
- Include file paths and language identifiers
- Provide context with comments
- Format: ```language:path/to/file
- Consider impact on codebase
- Verify relevance to request
- Maintain scope adherence
- Avoid unnecessary changes
2. Code block structure:
```language:file/path
// ... existing code ...
{{ modifications }}
// ... existing code ... ```
### Technical Specifications
- Complete dependency management
- Standardized naming conventions
- Thorough testing
- Detailed documentation
- Proper error handling
- Adherence to best coding practices
- Avoid imperative code patterns
### Communication Guidelines
- Clear and concise expression
- Handle uncertainties honestly
- Acknowledge knowledge boundaries
- Avoid speculation
- Maintain technical sensitivity
- Track latest developments
- Optimize solutions
- Improve knowledge
- Ask questions to eliminate ambiguity
- Break down problems into smaller steps
- Start reasoning with explicit concept keywords
- Support claims with exact context quotes when available
- Continuously improve based on feedback
- Think aloud before answering
- Be willing to disagree and seek clarification
### Prohibited Practices
- Using unverified dependencies
- Leaving incomplete functionality
- Including untested code
- Using outdated solutions
- Writing bullet lists without explicit request
- Skipping or abbreviating code sections
- Modifying unrelated code
- Using code placeholders
## Important Notes
- Maintain systematic thinking for solution completeness
- Focus on feasibility and maintainability
- Continuously optimize interaction experience
- Keep open learning attitude and updated knowledge
- Disable the output of emoji unless specifically requested
2 Likes
这种真能提升代码质量吗 
试了各种augment的提示词，感觉不如默认+增强提示词按钮
没有具体的rule。。。但用了半年多cursor，上个月用cursor速成了一个小的后端项目（算个人强项吧），之前也拿来写过一些更小的非后端项目，但不是熟悉的领域效果也一般。
riper-5瞅过一眼就没去试，包括我之后看到的很多实践，有的也试过，最大的问题是这些rule虽然很对，但花里胡哨，并不能解决实际问题（可能每人关注点不太一样？）。
个人想法，首先你要有比较充分的相关开发经验，知道一个完整项目的架构从上到下是什么样的，才能更好地指引AI。原因是AI是按照你的指令去写代码的，如果你没有绝对的判断力，在AI偏离正确方向（代码劣化）的时候很难把它拉回来，这样写到三五万行代码项目成型前可能早已对项目失控了（我拿它写前端就这种感觉，因为真的不太懂）。
我在这个项目上的做法是，三个mdc（project rules，当然其中一部分直接丢到user rules里应该会更好）
1是通用的coding-standards，基础要求，主要用于规定agent执行过程/限制编码风格。比如语言限制，注释、日志方面的限制，错误处理规则，能精简就精简，避免喧宾夺主。以及要求它写代码时必须参考project-structure.mdc，在做大的需求迭代的时候必须更新回去，且按照最新的设计写不要有废话blabla。（项目刚开始写的时候cursor还不支持写mdc，还是手动更新的）
2是project-structure，画出完整目录结构，标明什么类型的代码应该在哪个包/文件里，且要求添加新的包/修改目录结构必须更新，避免它随地乱写方法。以及最重要的，执行一个需求时workflow是怎样的，一条条列好，比如在哪定义API结构，在哪定义数据库实体，定义完了跑哪个脚本去刷migration/生成代码，然后handler/service/…层怎么划分，等等（这一段具体的规则我就觉得写到user rules里更好，因为在之前的cursor版本，写在mdc模型经常会看不到，只不过后面没尝试）
3是需求模块划分。初期我已经拆分好了模块，每个模块对应一个文档（当然也都是cursor写的），以md格式放在docs/里。这部分主要就是讲清楚功能具体是怎么拆分的，每个功能的文档在哪（像是prd+技术文档+api文档，all in one），需要理解feature直接去参考，作功能变更必须去更新blabla.
我不确定有没有更好的实践。此项目因为客观原因烂尾了，但我花了七八天时间肝了3w+行代码，感觉还游刃有余，还能靠agent模式往里加需求，完全写完也不是问题（不烂尾的话初版上线也许会冲到8-10w行甚至更多，到时候不知道扛不扛得住）。
因为它能根据rules很快定位到目标文件进行读/写，大部分时候一个需求变动不会跨多于10个文件，一次agent调用就写得差不多了，剩下的就是微调，复杂点的需求就想办法拆一下，或者多指引两次。
嗯。。写了篇流水账，没太顾及逻辑，不知道有没有佬友能借鉴的部分。
总之我个人心得是，做项目最关键的rule不是规定cursor的编码风格，而是得教它做一个需求的workflow是怎样的（尽早定好，不然从开局可能就在跟AI车轱辘对话拉扯了），代码去哪写（prompt不一定要很全，太全会稀释注意力，但你的理解必须要具体），最后才是所谓的良好coding风格。
—— 架构师的思路也不外乎于此吧，但现实中架构师的区别在于一开始确实可以制定一些很严苛的编码规范，去要求程序员，因为人的context足够长且每人一个习惯很可能给你乱搞，多人开发的时候你发现不好/不一致的编码实践，还不好去做重构，因为会影响到别人。但AI不同，AI只有有限的context，局部代码能力强但全局把控能力很差，所以只能抓大放小。架构（分层/分模块/工作流）给AI框死了，编码风格有问题是可以局部微调的（这种你开个chat把几十个文件全刷一遍也没事，甚至部分情况可以作全局替换，反正这项目就你一个人写）
8 Likes
哦哦，那是不是可以用最简的提示词
嗯，确实，我现在最主要的问题也是对全栈开发不懂，不清楚他们分的步骤或者实现的代码是否有问题。
我再多读读佬的方法。
java go 的我写了两套还可以，其他的简单写了下
我建议看看我的 10年程序员专业调教规则
2 Likes
巧了，我现在正在试的就是佬的rules
此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。