Kimi代码工程规范：角色设定与约束条件优化法

要让Kimi输出符合企业级工程规范的代码，核心在于精准控制其角色定位、约束条件、结构编排与自我校验机制。关键在于避免模型落入教学示例或伪代码式的自由发挥。

第一步是明确角色身份。对话初始直接声明具体职级与技术栈，例如：“你是一位拥有5年Python后端开发经验的高级工程师，曾供职于头部互联网企业，精通Flask、SQLAlchemy及PEP 8编码规范。”这种精确指令远胜于泛泛的“请专业一些”——Kimi会根据角色参数过滤掉简化写法，例如省略类型注解、缺失异常处理分支等新手级错误。务必使用肯定句定义角色与年限，切忌使用“类似资深工程师”这类模糊表述，否则模型极易退化至通用应答模式。

第二步，嵌入强制性工程约束。在需求描述之后追加可执行的硬性条款，每条独立成句：

• 所有函数必须包含Google风格docstring，涵盖Args、Returns、Raises三部分。
• 禁止使用print()调试，统一通过logging.getLogger(__name__).info()记录日志。
• 数据库操作必须封装于try/except块中，捕获SQLAlchemyError并重新抛出自定义BusinessError异常。

这些条款非建议而是强制规则。Kimi对“必须”“禁止”“统一”等动词响应敏感，一旦使用“尽量”“建议”，模型基本忽略约束。

第三步，定义文件结构与模块划分。两种方式：其一，给出树形骨架，例如：“按以下目录结构生成代码：/app/__init__.py、/app/models/user.py（含User ORM类）、/app/services/auth_service.py（含login_user函数）、/app/schemas/user_schema.py（含UserCreate Pydantic模型）。”其二，限定单文件内分区顺序，例如：“在同一个Python文件中按如下顺序组织：1. 导入区（标准库→第三方→本地）；2. 配置常量；3. 数据模型类；4. 业务函数；5. if __name__ == '__main__': 测试块。”若不指定结构，Kimi常将配置混入函数体，测试逻辑也可能直接写进主流程，导致耦合混乱。

最后，要求提供可验证的合规说明。追加指令：“在代码末尾另起一段，用中文逐条说明本实现如何满足以下三项：① PEP 8缩进与空行规范；② 异常分类处理机制；③ 接口参数校验位置。”此举迫使模型回溯自身输出逻辑，而非凭印象作答。若它无法写出合规说明，则代码本身大概率存在规范断层。

更直接的做法是：提供一段你以往写过的规范代码示例，明确指示“按此风格生成”。若无现成示例，以上方法已足够将Kimi的输出从“能跑”升级至“可上线”水准。