要让kimi生成可用、可维护、能直接嵌入项目的代码,必须用工程化语言精准描述需求:先定义角色与年限,再明确技术栈版本,禁用模糊词,用“必须”“禁止”“统一”列出硬性约束,结构化描述业务逻辑链条、数据流向与边界情况,并提供可验证的代码样例与文件规范。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜

要让Kimi生成可用、可维护、能直接嵌入项目的代码,必须用工程化语言精准描述需求,而不是模糊说“写个登录页”或“做个API”。模型不会主动补全你没说清楚的约束,它只忠实地执行你输入的每一条明确指令。
先定义角色,再提需求
第一步:在对话开头用【肯定句】声明工程师身份与年限,例如:“你是一位有5年Vue3+TypeScript全栈开发经验的资深工程师,就职于一线互联网公司,熟悉Pinia状态管理、Vite构建流程和ESLint+Prettier规范。”
第二步:紧接着说明技术栈与框架版本,例如:“项目基于Vue3.4、TypeScript 5.4、Pinia 2.2,使用<script setup>语法,所有组件需支持SSR兼容。”</script>
第三步:禁止使用“类似”“大概”“差不多”等模糊词——Kimi会退回到教学示例风格,生成缺少类型定义、跳过错误边界、无日志埋点的玩具代码。
嵌入硬性工程约束
方法一:用“必须”“禁止”“统一”三类动词逐条列出不可协商的规则,每条单独成句:
所有API调用必须封装在composable中,命名格式为useXxxQuery/useXxxMutation
禁止在组件内直接调用fetch或axios,所有网络请求走封装层
每个composable必须导出明确的返回类型接口,且类型名以UseXxxReturn结尾
所有异步操作必须包含loading、error、data三态,并在模板中显式处理空数据与错误提示
【关键提醒】这些不是建议,是强制执行条件。Kimi对“必须”响应准确;而“尽量”“建议”会被完全忽略。
结构化描述业务逻辑
第一步:按“触发动作→业务规则→预期输出”链条组织语言。例如不要说“用户能改密码”,而要说:“当用户在个人设置页点击‘修改密码’按钮后,前端需校验新密码强度(至少8位,含大小写字母和数字),调用/api/users/password/reset接口提交PATCH请求,成功后清空Token并跳转至登录页。”
第二步:明确数据流向与依赖项。例如:“用户列表组件需从Pinia store的userStore.users获取数据,该store已通过useAsyncState预加载,组件内不再重复发起请求。”
第三步:标注边界情况。例如:“搜索框支持空字符串提交,此时应返回全部用户;若后端返回404,则显示‘暂无匹配用户’文案,不抛出全局错误提示。”
给出可验证的输出样例
方法一:提供一段你期望生成的代码片段作为锚点。例如:“请生成一个useUserList composable,结构参考如下:
export function useUserList() {
const users = ref
const loading = ref(false);
const error = ref
async function fetchUsers() { ... }
return { users, loading, error, fetchUsers };
}
方法二:指定文件层级与命名规范。例如:“生成的代码应保存为src/composables/useUserList.ts,不得创建额外目录,不得合并到其他文件。”
这一步能让Kimi对齐你的项目结构习惯,避免生成“合理但无法直接放入工程”的代码。
拒绝自然语言泛泛而谈
直接删掉这些无效表达:“帮我写个好看的页面”“要专业一点”“像大厂那样做”“最好能扩展”。Kimi无法解析主观形容词,只会按通用模板填充。
把“好看”换成“遵循Ant Design 5.12色值体系,主色#1677ff,按钮圆角6px,字体使用Inter,行高1.5”。
把“能扩展”换成“所有功能点通过defineProps接收配置对象,props接口名为UserListConfig,含searchable:boolean、paginated:true、showAvatar:true三个可选字段”。










