1. 项目缘起当SBTI成为程序员圈的“社交货币”最近我的技术社区和朋友圈几乎被“SBTI”刷屏了。一开始我还以为是某个新的技术框架或者云服务仔细一看才发现这玩意儿和代码没半毛钱关系是那个火遍全网的“十六型人格测试”。看着同行们纷纷晒出自己的“建筑师INTJ”、“逻辑学家INTP”标签讨论着哪种人格更适合做架构师哪种人格容易写出“屎山”代码场面一度非常魔幻。作为一个老程序员我的第一反应是这不科学。一个为大众设计的、基于心理学模型的性格测试其问题和语境与软件开发这个高度专业化、逻辑密集的领域存在巨大的错位。它无法评估一个人对递归的理解深度、调试复杂并发问题的耐心或者面对需求频繁变更时是选择重构还是打补丁的决策倾向。然而它的流行恰恰说明了一个强烈的潜在需求程序员群体渴望一种能够定义、理解甚至“标签化”自身技术特质与工作风格的框架。这种框架不仅能用于自我认知和职业发展参考更能成为团队协作、技术招聘中一个有趣的、低成本的沟通工具。既然大众有MBTI我们为什么不能有专属于程序员的“CBTI”呢这里的“C”可以理解为“Coder”、“Craft”或者“Code”。这个想法让我非常兴奋。与其等待一个可能永远不会出现的“官方标准”不如自己动手做一个真正贴近我们日常、能反映技术人思维模式的测评工具。于是我决定利用一个周末的时间快速验证这个想法目标是产出一个可用的最小可行产品MVP并且秉承开源精神将整个过程和代码全部公开。我选择了Cursor作为本次开发的核心工具。原因很简单我想极致地聚焦于“想法验证”和“产品构建”本身而不是把大量时间耗费在环境配置、基础代码编写和常见的语法错误调试上。Cursor的AI编程助手能力正好能充当一个不知疲倦的、知识渊博的“结对编程”伙伴帮助我快速完成从原型设计、前端界面到后端逻辑乃至测评题库设计的全流程。下面我就来详细拆解这个“程序员版CBTI”从构思到上线的完整开发过程以及其中关于AI辅助编程的实战心得。2. 核心设计如何定义程序员的“性格维度”做一个测评首要问题不是写代码而是设计模型。我们测评的到底是什么如果直接照搬MBTI的四个维度内倾/外倾、实感/直觉、情感/思考、判断/感知那无异于新瓶装旧酒毫无意义。我们必须找到真正能区分程序员工作习惯和技术偏好的核心维度。经过一番思考和与几个朋友的脑暴我初步筛选出了四个我认为最具代表性的维度并赋予了它们程序员的“黑话”式命名### 2.1 维度一架构观 —— “设计驱动” vs “演进驱动”这个维度衡量的是你在项目初期面对一张白纸时的本能反应。设计驱动型这类开发者信奉“谋定而后动”。在写第一行代码之前他们倾向于先画UML图设计清晰的模块边界、定义接口契约、选择合适的设计模式。他们享受构建清晰、可扩展的架构蓝图的过程认为前期多花一小时设计后期能节省十小时的重构。风险在于容易陷入“过度设计”在需求不明朗的早期阶段构建了不必要的复杂性。演进驱动型这类开发者信奉“让代码自己说话”。他们更愿意先快速实现一个可工作的、最简单的版本MVP然后通过不断重构来适应变化、改善设计。他们擅长在代码演化的过程中发现真正的抽象和模式认为“没有银弹”最好的架构是随着对问题域理解的深入而自然浮现的。风险在于代码库可能在缺乏引导的情况下演变成难以维护的“泥球架构”。### 2.2 维度二调试哲学 —— “逻辑演绎派” vs “实证实验派”这个维度描述的是当你面对一个诡异Bug时的第一反应。逻辑演绎派他们是代码福尔摩斯。遇到问题首先会静下心来阅读错误堆栈、相关代码段在脑中构建执行流程通过逻辑推理逐步缩小嫌疑范围直到定位根因。他们依赖对系统原理的深刻理解喜欢说“让我想想这里的数据流应该是...”。这种方式精准且治本但对复杂分布式系统的全局状态追踪能力要求极高。实证实验派他们是代码实验室主任。他们的第一反应是“让我们来做个实验”。通过添加日志、编写单元测试复现、使用调试器逐步执行、甚至临时修改代码来验证假设。他们信奉“眼见为实”通过快速迭代的假设-验证循环来逼近真相。这种方式直观高效尤其在面对难以理清逻辑的第三方库问题时优势明显但可能缺乏对问题本质的深入洞察。### 2.3 维度三技术选型倾向 —— “追新冒险家” vs “稳定保守派”这个维度关乎你面对新技术时的态度。追新冒险家对GitHub Trending榜、Hacker News上的新框架/工具充满好奇乐于在个人项目或风险可控的模块中尝试。他们相信新技术带来的效率提升和未来优势愿意承担早期生态不完善、文档缺失的风险。他们是团队的技术雷达。稳定保守派更倾向于选择经过大规模生产环境验证、社区活跃、有长期支持LTS版本的技术栈。他们认为稳定性、可维护性和招聘成本比“酷”更重要。他们的口头禅可能是“这个版本号前面带1了吗”。### 2.4 维度四协作风格 —— “文档契约师” vs “口口相传者”这个维度体现在你如何与队友共享知识。文档契约师坚信“代码未动文档先行”。他们擅长撰写清晰的API文档、架构决策记录ADR、详细的README和代码注释。他们认为文档是团队协作的基石是避免重复沟通和知识流失的最佳实践。口口相传者更倾向于通过即时沟通如站会、一对一讨论来同步信息。他们认为文档容易过时而面对面的交流更高效、更能传递上下文。他们可能更擅长绘制白板图来解释复杂设计。基于这四个维度每个维度有两个倾向最终可以组合成16种“程序员人格类型”。我为每种类型构思了一个有趣的代号和简短描述例如“架构师设计/演绎/稳定/文档”、“敏捷先锋演进/实验/追新/口传”等。3. 技术实现用Cursor快速构建全栈应用有了清晰的产品设计接下来就是用技术实现它。我的目标是极速开发因此技术栈的选择原则是简单、直接、AI友好。前端Vite React TypeScript Tailwind CSS。Vite的快速热重载对开发体验提升巨大React组件化与UI状态管理清晰TypeScript能提供良好的类型提示这对与AI协作至关重要能减少上下文歧义Tailwind CSS则能让我在不离开HTML/JSX的情况下快速构建美观的界面无需操心CSS文件。后端/逻辑Next.js API Routes。为了简化部署我直接使用Next.js的全栈能力。测评的计算逻辑根据答案计算维度得分并映射到类型并不复杂一个API路由足矣。数据库暂时不需要。测评结果可以暂时存储在客户端LocalStorage或通过一个简单的JSON文件管理MVP阶段完全够用。部署Vercel。与Next.js是天作之合一键部署自带全球CDN、HTTPS对于这种小型应用来说免费额度完全足够。整个开发过程我深度依赖了Cursor的以下功能### 3.1 用Chat指令生成项目骨架和基础组件项目初始化我不再需要手动敲npm create vitelatest然后一步步选择。我直接在Cursor的Chat面板中输入请帮我创建一个基于Vite React TypeScript Tailwind CSS的前端项目。项目名称设为“dev-personality-test”。使用pnpm作为包管理器。并创建以下初始页面结构 1. 一个欢迎页/包含项目简介和开始测试按钮。 2. 一个测试页/test用于展示题目和选项。 3. 一个结果页/result用于展示测评结果。 请生成必要的路由配置和基础组件框架。Cursor在几秒钟内就生成了完整的package.json、vite.config.ts、tailwind.config.js以及App.tsx、pages/目录下的组件文件。我检查了一下配置完全正确甚至自动安装了react-router-dom并配置好了路由。这为我节省了至少半小时的初始化时间。### 3.2 让AI协助设计题库与测评逻辑这是本项目的核心数据。我并没有自己绞尽脑汁去想20道题而是向Cursor描述了每个维度的定义和倾向让它帮我生成候选题目。我正在创建一个程序员性格测评有以下四个维度...此处粘贴维度定义。 请为每个维度生成3-4道情景选择题。题目场景应贴近程序员日常工作如代码审查、技术选型会议、线上故障处理等。每个题目提供两个选项分别对应维度的A端和B端倾向。选项描述要具体、有场景感避免抽象词汇。Cursor生成的题目质量出乎意料地高。例如针对“调试哲学”维度它生成了一道题题目当你负责的微服务在凌晨突然出现CPU飙高报警你的第一反应是A. 立刻登录服务器查看监控图表如CPU使用率、GC日志、线程堆栈分析异常时间点的前后变化并根据服务最近一次的变更记录进行逻辑推理推测可能的原因。B. 立刻在预发环境尝试复现同时给相关代码段添加更详细的指标埋点和日志然后通过压测工具模拟流量观察日志输出和资源变化定位问题代码块。这完美地对应了“逻辑演绎派”和“实证实验派”。我对这些题目进行了微调和润色最终形成了包含20道题目的题库以JSON格式存储。### 3.3 编写核心计算与类型映射逻辑接下来是实现打分和类型判断。我在lib/目录下创建了calculateResult.ts。通过CmdK打开代码编辑模式我直接告诉Cursor我的数据结构// 已有接口定义 interface Answer { questionId: number; dimension: ‘arch’ | ‘debug’ | ‘tech’ | ‘collab’; tendency: ‘A’ | ‘B’; // A代表维度第一个倾向如设计驱动B代表第二个如演进驱动 } interface DimensionScore { arch: number; // -5 到 5负值偏A正值偏B debug: number; tech: number; collab: number; } // 请实现一个函数 calculateDimensionScores(answers: Answer[]): DimensionScore // 并实现一个函数 getTypeFromScores(scores: DimensionScore): string根据分数映射到16种类型之一。Cursor几乎是一气呵成地写出了正确的累加逻辑和映射判断。我只需要补充上我预先定义好的16种类型名称和描述的映射表即可。整个过程流畅得就像在和一个理解我需求的资深同事结对编程。### 3.4 构建交互式测试界面对于测试页面我希望每道题单独呈现有清晰的进度指示并且选项按钮有友好的交互反馈。我使用Cursor的编辑功能在已有的TestPage组件框架内通过自然语言描述来生成JSX和状态逻辑。我输入“在这里添加一个状态管理当前题号currentQuestionIndex。显示一个进度条。根据当前题号从题库中渲染题目和两个选项按钮。点击选项后保存答案并自动跳转到下一题。所有题目答完后跳转到结果页。”Cursor准确地添加了useState、useEffect并生成了对应的JSX结构包括进度条的计算 ((currentQuestionIndex / totalQuestions) * 100%)。我在此基础上用Tailwind CSS快速美化了按钮和卡片样式整个过程非常直观。4. 踩坑与优化AI编程并非“许愿机”尽管Cursor极大地提升了效率但开发过程并非一帆风顺。完全依赖AI也会遇到一些典型的“坑”需要开发者保持清醒的判断。### 4.1 坑一AI的“想当然”与上下文丢失在让Cursor生成结果页组件时我要求它“根据传入的typeCode如 ‘ADSC’显示对应的类型名称、描述和一张代表图片”。它确实生成了逻辑但图片部分它直接写死了像“/images/architect.png”这样的路径。问题在于我根本没有准备这些图片AI也不会自动为我生成图片。教训AI擅长处理已有逻辑和已知模式的延伸但它无法创造项目中不存在的资源如图片、特定的外部API数据。对于这类需求要么提前准备好资源要么在提示词中明确说明“暂时用占位符或纯色div代替”要么自己手动补充。最终我选择使用 Tailwind CSS 的颜色工具 生成一些漂亮的渐变色块来代表不同类型效果反而更简洁统一。### 4.2 坑二对复杂状态管理的“短视”在测试初期我将所有答案用一个数组useState管理。随着我增加“允许用户返回上一题修改答案”的功能时问题来了。简单的状态数组在处理中间插入、修改时需要小心处理不可变性。我向Cursor描述了这个新需求它给出的修改方案在边缘情况如从最后一题返回第一题多次修改下出现了状态不同步的Bug。教训对于稍复杂的状态逻辑尤其是存在多个相互关联的状态变量时AI生成的代码可能只覆盖“主干道”场景缺乏对边缘情况的鲁棒性处理。这时将复杂状态逻辑抽取到自定义Hook或使用状态管理库如Zustand、Jotai是更好的选择。我后来将答题状态和逻辑抽到了一个useTestStore的Zustand Store中结构清晰了许多AI在理解了这个Store的结构后也能更好地协助我编写相关组件。### 4.3 坑三过度依赖导致“理解脱节”在某个功能点我连续通过Chat让Cursor修改了四五次代码。当我回过头想自己调整某个细节时突然发现我对这块代码的“掌控感”变弱了需要重新阅读才能理解其当下的逻辑。这有点像“复制粘贴编程”的升级版——“提示词编程”如果节奏太快容易导致开发者与代码细节脱节。心得将AI视为“高级自动完成”和“即时问答伙伴”而非“全权委托的开发者”。我的做法是对于每个新功能或模块先自己构思大致的数据流和组件结构然后用清晰的注释或伪代码写在文件里再让Cursor去填充实现。或者在Cursor生成代码后我必须一行行阅读、理解甚至手动运行一下确保我完全明白它在做什么。保持“代码所有权”意识至关重要。5. 部署与开源让想法快速落地与传播开发完成后部署到Vercel的过程简单得令人发指。将代码推送到GitHub仓库在Vercel控制台导入项目它自动识别出是Next.js项目配置几乎无需改动点击部署几分钟后一个全球可访问的链接就生成了。至于开源我选择了MIT许可证因为它最宽松允许任何人自由使用、修改和分发代码。我在项目根目录创建了README.md这是项目的门面。我让Cursor帮忙起草了一个初版请为我的“程序员性格测评”项目撰写一个README.md文件。内容应包括项目简介、四个测评维度的简要说明、技术栈、本地运行指南、如何参与贡献以及在线体验链接。语气保持友好、鼓励。Cursor给出了一个结构清晰、内容全面的草稿。我在此基础上补充了更详细的“项目背景”故事和“开发心得”章节让README更具个人色彩和参考价值。### 5.1 开源后的意外收获项目开源后我将其分享到了几个技术社区。出乎意料的是吸引大家的不仅仅是测评本身更多的是“用Cursor快速构建一个完整应用”的这个过程。很多开发者对如何在具体项目中有效利用AI编程助手非常感兴趣。我在README和社区讨论中详细记录的开发流程、遇到的坑以及解决方案成了比测评工具本身更受欢迎的内容。这也让我反思在AI辅助编程逐渐普及的今天分享“如何与AI协作”的方法论和实战经验可能和分享具体的代码实现同样重要甚至更有价值。6. 总结与展望AI编程下的“新常态”这个周末项目让我深刻体会到像Cursor这样的AI编程助手正在改变个人开发者和小团队验证想法、构建产品的成本曲线和速度极限。它极大地压缩了从“想法”到“可运行产品”之间的“机械性编码”时间让开发者能更专注于核心的产品设计、逻辑和用户体验。对于想尝试类似项目的朋友我的建议是明确边界想清楚你要解决的核心问题是什么比如做一个有趣的测评并设计好产品模型。AI是实现工具不是产品经理。学会提问与AI协作的关键是“精准描述”。把你对代码的需求像给一个资深但需要详细指令的同事描述一样说出来。包括输入、输出、边界条件、期望的代码风格。保持掌控永远不要完全放弃对代码的理解。Review AI生成的每一段逻辑特别是涉及状态和副作用的地方。你是船长AI是强大的引擎和雷达但航线需要你来把握。拥抱迭代第一版代码不完美没关系。利用AI快速实现MVP上线获取反馈然后继续利用AI快速迭代改进。这个循环可以非常快。这个“程序员版CBTI”项目本身还有很多可以完善的地方比如增加更科学的信效度验证、设计更丰富的题目库、甚至引入简单的机器学习来优化类型匹配算法。但更重要的是它作为一个案例展示了在AI工具的加持下一个开发者如何用极短的时间、极低的成本将一个有趣的念头变成现实并分享给全世界。这或许就是未来很长一段时间里独立创造者的“新常态”。