您现在的位置是:首页 > 文章详情

调试慢、加班多?7 个不用 ChatGPT 的效率习惯,半年省出 200 小时 | 葡萄城技术团队

日期:2025-09-25点击:31

调试慢、加班多?7 个不用 ChatGPT 的效率习惯,半年省出 200 小时

我们都见过那些 “10 倍效率开发者” 的段子 —— 有人把他们当偶像,也有人觉得是噱头。

但真相是:成为 “10 倍开发者”,从来不是靠天生奇才、每天肝 20 小时,更不是灌着红牛重写 Linux 内核。

关键在于习惯—— 那些不起眼的、没人在意的小习惯。直到有一天,你会发现自己的产出效率已经高得惊人。

过去几年,我慢慢养成了 7 个习惯,不知不觉就把自己 “升级” 成了曾经羡慕的 “10 倍效率版”—— 全程没靠 AI 辅助工具。

1.🧱 写 “能生成代码的代码”

不是指大模型(LLM),而是自己写脚本、生成器和脚手架工具。

我养成了 “能自动化就不手动” 的习惯,比如:

  • 自动生成重复的模板文件(如 Vue/React 组件模板、接口请求模板)
  • 一键生成 CRUD 接口的基础代码(含参数校验、返回格式封装)
  • 自动创建测试桩(如单元测试的初始化代码)
  • 甚至自己配置 GitHub Actions 工作流(自动跑测试、打包部署)

只要某个操作我要重复做两次以上,就会把它抽象成工具。久而久之,我有了一套自己的 “效率工具箱”,在客户项目和个人开发中省了几十个小时。

为什么这能提升 10 倍效率?

你不用再反复解决同一个问题,相当于把自己的精力 “放大” 了 —— 一次写工具,后续无数次复用。

国内开发者实操示例:

用 Node.js 写一个简单脚本,自动生成 React 函数组件模板(避免每次手动写导入、Props 定义):

// create-react-component.js
const fs = require('fs');
const path = require('path');
// 接收组件名参数(如:UserCard)
const componentName = process.argv[2];
if (!componentName) {
  console.error('请传入组件名,示例:node create-react-component.js UserCard');
  process.exit(1);
}
// 组件模板内容
const componentContent = `import React from 'react';
import PropTypes from 'prop-types';
/**
 * ${componentName} 组件:[此处可补充组件功能描述]
 */
const ${componentName} = ({ title, className }) => {
  return (
    <div classname="{\`\${componentName.toLowerCase()}" \${classname || ''}\`}>
      {title &amp;&amp; <h3>{title}</h3>}
      {/* 组件内容待补充 */}
    </div>
  );
};
// Props类型校验
${componentName}.propTypes = {
  title: PropTypes.string, // 标题(可选)
  className: PropTypes.string, // 自定义样式类(可选)
};
// Props默认值
${componentName}.defaultProps = {
  title: '',
  className: '',
};
export default ${componentName};
`;
// 生成组件文件(如:src/components/UserCard/UserCard.jsx)
const componentDir = path.join(__dirname, 'src/components', componentName);
fs.mkdirSync(componentDir, { recursive: true });
fs.writeFileSync(path.join(componentDir, `${componentName}.jsx`), componentContent);
console.log(`✅ ${componentName} 组件已生成:${componentDir}`);

使用时只需执行 node create-react-component.js UserCard,1 秒生成规范的组件文件,避免重复手写模板。

2.🧭 为 “未来的自己” 写代码

我不再只盯着 “当下能跑通”,而是开始为 6 个月后读这段代码的人(通常还是我自己)考虑。

具体会做这些事:

  • 写有意义的 Git 提交信息(不是 “fix bug”,而是 “fix: 修复 Safari 浏览器上传按钮崩溃问题”)
  • 函数名要清晰(比如用 getUserOrderList 而非 getList)
  • 写 “有用的注释”(不是 “// 定义变量 a”,而是 “// 存储用户订单状态:0 - 待支付,1 - 已完成”)
  • 规整的文件结构(比如按 “页面 / 组件 / 工具 / 接口” 分类,而非随意堆放)
  • 最重要的:写代码前先写 README.md—— 这会强迫你先理清需求和逻辑,避免边写边改。

为什么这能提升 10 倍效率?

你不用再花时间 “破译” 自己过去写的代码。未来的你(或团队同事)能直接看懂、直接改,速度自然快。

国内开发者实操示例:

  1. 规范的 Git 提交信息(参考 Angular 提交规范,国内团队常用):
# 格式:类型(模块): 描述
feat(订单模块): 新增订单导出Excel功能
fix(用户模块): 修复手机号格式校验不支持177号段的问题
docs: 更新README中的接口调用示例
style: 调整登录页面按钮样式(不影响逻辑)
refactor(工具函数): 重构日期格式化函数(性能优化)
test: 为支付接口添加单元测试

2.项目 README 核心结构(国内前端项目常用):

# 电商管理系统(前端)
## 项目介绍
基于Vue3 + Element Plus开发的电商后台管理系统,包含商品管理、订单管理、用户管理等模块。
## 环境准备
- Node.js: v16+
- npm: v8+ 或 yarn: v1.22+
## 快速启动
1. 克隆代码:git clone https://gitee.com/your-name/ecommerce-admin.git
2. 安装依赖:npm install (若报错可尝试 npm install --legacy-peer-deps)
3. 开发环境启动:npm run dev
4. 打包构建:npm run build:prod
## 目录结构
src/
├── api/       # 接口请求函数(按模块分类)
├── components/ # 公共组件
├── views/     # 页面组件(按业务模块分类)
├── utils/     # 工具函数(日期、加密等)
└── store/     # Pinia状态管理
## 注意事项
1. 开发时需配置.env.development中的VITE_API_BASE_URL(后端接口地址)
2. 提交代码前需执行 npm run lint 修复代码格式问题

3.📕 调试前先 “记录问题”

遇到 bug 时,我不会直接冲进去改代码,而是先写一段 “调试日志”,比如:

- 问题:移动端H5页面点击“提交订单”按钮无响应(仅在微信内置浏览器出现)
- 假设:可能是微信浏览器对FormData的处理兼容问题,或点击事件被遮罩层拦截
- 计划:
  1. 用微信开发者工具模拟微信浏览器环境,复现问题
  2. 检查按钮DOM层级(是否有透明遮罩层覆盖)
  3. 打印FormData数据,确认参数是否正确传递
  4. 尝试用addEventListener绑定click事件(替代v-on:click)

我会把这段日志记在语雀(国内常用文档工具,比 Notion 访问更稳定)或本地 Markdown 文件里,再开始调试。

为什么这能提升 10 倍效率?

写下来的过程会强迫你理清思路 —— 避免漫无目的地试错,而是有计划地排查,调试自然更高效。

国内开发者实操示例:

用语雀创建 “调试日志” 文档模板,每次遇到 bug 时按模板填写:

字段 内容示例
问题出现时间 2024-09-10 14:30(用户反馈,测试环境未复现,生产环境偶现)
影响范围 仅 iOS 端微信浏览器(版本 8.0.35+),约 5% 用户
问题描述 点击 “确认支付” 后无加载状态,也不跳转支付页,控制台无报错
初步假设 1. 支付接口请求超时未处理;2. iOS 微信对 axios 的 abortController 支持有问题
排查步骤 1. 生产环境添加日志监控(记录接口请求状态);2. 用 iOS 真机 + 微信开发者工具复现;3. 替换 axios 为 fetch 重试
解决结果 原因:iOS 微信浏览器中,axios 的 timeout 设置超过 3000ms 会被拦截,改为 2500ms 后正常

4.🛠 为自己造 “小工具”

慢慢的,我攒了一堆自己用的小工具:

  • 一个 CLI 工具:批量重命名截图(比如把 “微信截图 2024091015.png” 改成 “订单页 bug-20240910.png”)
  • 一个 Python 脚本:把 GitHub 仓库的 README 和核心代码转换成 PDF(方便离线看开源项目文档)
  • 一个本地 SEO 工具:抓取某关键词的百度长尾推荐(比如输入 “前端性能优化”,抓百度下拉框的 “前端性能优化方案 2024” 等)
  • 一个 VSCode 代码片段生成器:输入 “vue3comp” 就能生成 Vue3 组件模板(含 Props、生命周期)

这些不是 “产品”,就是解决自己日常痛点的 “小玩具”,但能省很多重复操作的时间。

为什么这能提升 10 倍效率?

每天开发中会有很多 “微小的麻烦”(比如手动改 10 张截图名、重复写组件模板),这些小工具能把这些麻烦 “一键消除”,积少成多就是巨大的效率提升。

国内开发者实操示例:

写一个 Python 脚本,批量处理接口测试报告(把 Postman 导出的 JSON 报告转换成 Excel,方便给测试同学看):

# postman2excel.py
import json
import pandas as pd
from openpyxl import Workbook
# 读取Postman导出的JSON报告
with open('postman-report.json', 'r', encoding='utf-8') as f:
    report_data = json.load(f)
# 提取关键数据(用例名、请求URL、状态、响应时间)
test_cases = []
for item in report_data['run']['executions']:
    test_cases.append({
        '用例名称': item['item']['name'],
        '请求URL': item['request']['url']['raw'],
        '测试状态': '通过' if item['assertions'][0]['passed'] else '失败',
        '响应时间(ms)': item['response']['responseTime'],
        '错误信息': item['assertions'][0]['error']['message'] if not item['assertions'][0]['passed'] else ''
    })
# 写入Excel
df = pd.DataFrame(test_cases)
df.to_excel('接口测试报告.xlsx', index=False, engine='openpyxl')
print(f"✅ 已生成接口测试报告,共{len(test_cases)}条用例")

使用时只需把 Postman 报告导出为 JSON,执行脚本就能生成 Excel,避免手动复制粘贴。

5.📅 给 “深度工作” 划时间块

我会在日历里设置 “无代码干扰时段”,这段时间只做 “需要专注的事”,比如:

  • 不看企业微信 / 钉钉消息
  • 不刷掘金 / 知乎
  • 不处理 “紧急但不重要” 的代码评审(比如格式调整类的 PR)

我的飞书日历(国内团队常用日历工具)里,每天会有 1-2 个 90 分钟的块,标题标着 “深度工作:核心功能开发” 或 “深度工作:技术债务清理”,这段时间会开启 “免打扰模式”。

为什么这能提升 10 倍效率?

频繁切换任务(比如写代码时突然回消息、看 PR)会严重破坏专注力,而深度工作需要 “进入状态”—— 时间块能帮你守住专注力,一旦进入状态,效率会翻倍。

国内开发者实操示例:

深度工作时间块规划(飞书日历):

时间段 内容 规则
09:30-11:00 核心功能开发(支付模块) 关闭企业微信通知,手机调静音
14:00-15:30 技术方案设计(用户认证) 不打开浏览器(除必要的文档页面)
16:00-17:30 接口联调(与后端同步) 仅保留与后端的沟通窗口,其他软件关闭

避免干扰小技巧:

  1. 提前在企业微信状态标注 “深度工作中,11 点后回复”
  2. 用 VSCode 的 “专注模式”(隐藏侧边栏,只保留代码编辑区)
  3. 喝一杯水再开始 —— 避免中途起身打断专注

6.🧠 借鉴 “工作流”,而不只是代码

以前我只会从 Stack Overflow 抄代码,现在我会刻意观察:

  • 优秀 GitHub 仓库(比如 Element Plus)是怎么配置 CI/CD 的(比如提交代码后自动跑测试、生成文档)
  • 开源项目(比如 Vue3)是怎么管理版本发布的(比如 alpha 测试、beta 反馈、正式版发布流程)
  • 独立开发者(比如国内的技术博主)是怎么自动化部署的(比如用 Vercel+Gitee Pages 自动部署静态博客)

然后把这些 “工作流” 改成适合自己团队的模式,融入日常开发。

为什么这能提升 10 倍效率?

代码是 “一次性的”,但工作流是 “可复用的”—— 一套好的工作流能让你每次开发、测试、部署都少走弯路,长期下来效率差巨大。

国内开发者实操示例:

借鉴 Element Plus 的 GitHub Actions 工作流,配置自己项目的 “提交代码自动检测”:

# .github/workflows/code-check.yml
name: 代码检测(lint + 单元测试)
on: [push, pull_request] # 提交代码或PR时触发
jobs:
  code-check:
    runs-on: ubuntu-latest
    steps:
      - name: 拉取代码
        uses: actions/checkout@v3
      
      - name: 安装Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '16'
          cache: 'npm' # 缓存npm依赖,加速安装
      
      - name: 安装依赖
        run: npm install --legacy-peer-deps
      
      - name: 代码格式校验(ESLint)
        run: npm run lint
      
      - name: 单元测试
        run: npm run test:unit

配置后,每次提交代码都会自动跑 ESLint 和单元测试,有问题会直接在 GitHub 上提示,避免把错误带到后续流程。

7.🪞 每周 “复盘”—— 哪怕一个人也要做

每个周五下班前,我会花 10 分钟回答三个问题,记在自己的 “效率日志” 里:

  1. 这周什么事做得顺利?(比如:用新写的脚本自动生成了 5 个组件,省了 1 小时)
  2. 什么事拖慢了进度?(比如:测试环境数据库频繁断开,每次重连要等 5 分钟)
  3. 下周能自动化 / 改进什么?(比如:写一个脚本监控测试环境数据库状态,断开时自动重启)

这个小仪式帮我发现了很多 “隐形的时间浪费”,每周都能比上周高效一点点。

为什么这能提升 10 倍效率?

没有复盘就没有进步 —— 通过每周回顾,你能持续优化自己的工作方式,避免在同一个坑上反复浪费时间,效率自然会越来越高。

国内开发者实操示例:

每周复盘表格(用飞书表格记录,方便长期追踪):

日期 做得顺利的事 拖慢进度的事 下周改进计划
2024-09-06 1. 用脚本批量处理了 30 个接口文档;2. 提前 1 天完成订单模块开发 1. 后端接口文档频繁变更,改了 3 次前端请求;2. 本地环境启动要等 2 分钟 1. 与后端约定 “接口变更需提前 1 天同步”;2. 优化 webpack 配置,减少启动时间
2024-09-13 1. 复用了之前写的 Excel 导出工具;2. 单元测试覆盖率提升到 80% 1. 微信浏览器兼容问题排查了 4 小时;2. 代码评审反馈来回改了 2 次 1. 整理微信浏览器兼容问题清单;2. 提交 PR 前先自查代码规范

🚀 最后想说:“10 倍效率” 不是神话,是 “积少成多”

没有什么 “一键变身” 的魔法。

“10 倍效率” 是靠无数个小改进、小习惯、小工具堆出来的 —— 每天省 10 分钟,每周省 1 小时,半年后你会发现自己的效率已经远超过去。

而且,这真的不需要 ChatGPT,也不需要超能力,只需要三点:

  • 有意识地观察 “哪里能优化”
  • 坚持做那些 “不起眼但有用的事”
  • 有点 “抠门”—— 总想在不牺牲质量的前提下,多省一点时间

💬 该你了

作为开发者,你有什么 “不起眼但提效明显” 的小习惯或小工具?

欢迎在评论区分享 —— 我很乐意 “借鉴”(当然会注明出处 😉)

扩展链接

葡萄城AI搜索

原文链接:https://my.oschina.net/powertoolsteam/blog/18693302
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。

文章评论

共有0条评论来说两句吧...

文章二维码

扫描即可查看该文章

点击排行

推荐阅读

最新文章